Print modal throws error when using embeddedPrint in multi-threaded WASM mode

Technical Support
1

Product:
WebViewer using WebComponent (not iframe)

Product Version:
11.9.0

Please give a brief summary of your issue:

When using WebViewer.WebComponent() to initialize WebViewer, printing only passes 1 page to Chrome’s print dialog regardless of the page count or page range selected.

Please describe your issue and provide steps to reproduce it:

  1. Initialize WebViewer using WebViewer.WebComponent()
  2. Load a multi-page PDF (e.g., 11 pages)
  3. Click the print button in the toolbar
  4. In the Print Settings modal, select “All” pages (shows “Total: 11 pages” correctly)
  5. Click Print
  6. Chrome’s print dialog opens showing “1 sheet of paper” instead of 11

Expected behavior:
Chrome print dialog should show all 11 pages (or the selected page range).

Workaround:
Switching from WebViewer.WebComponent() to WebViewer.Iframe() fixes the issue - printing works correctly with all pages appearing in Chrome’s print dialog.

// Broken:
instance = await WebViewer.WebComponent({...}, viewerElement);

// Works:
instance = await WebViewer.Iframe({...}, viewerElement);
3

Hello, I’m AiRon, an automated tech support bot :robot: While you wait for one of our customer support representatives, I can help you with your question.



It seems like you’re encountering an issue with printing multi-page documents using WebViewer as a Web Component in Chrome. This can happen due to the way Chrome handles printing in certain contexts, particularly with web components.

Some things you can try:

  • Ensure that your WebViewer version is up-to-date as newer versions might have addressed this issue.

  • Consider using a workaround by switching to the Iframe mode if possible, as it seems to work correctly for you.

  • Check if any CSS or JavaScript in your project might be interfering with the print functionality.

  • Look into the possibility of using server-side rendering for PDFs, which might handle printing differently.




Here are some resources that might help you:



Hopefully, this helps you solve your problem while you wait for a human to get back to you.

4

Hello Wes,

Than you for contacting Apryse Forums.

I’m unable to reproduce this issue on our Showcase. https://showcase.apryse.com/

Can you test on the Showcase and see if the issue is still reproducible?

image
image1962×1274 216 KB

Please also try the following:

  1. Updating your Chrome browser
  2. Testing on different machines
  3. Checking for any console/network errors when printing
  4. Try using instance.UI.useEmbeddedPrint(true); before printing

Best Regards,
Darian

5

Hi Darian, so I have some new findings, but there’s still an issue.

Changing to embedded printing did fix the issue with only “1 page” showing up in the Chrome Print Preview modal. However, doing that caused other issues, detailed below.

Update with findings:

Thanks Darian for the suggestions. I’ve done extensive testing and found the root cause and a workaround:

Root Cause: The issue appears to be related to threaded WebAssembly (wasm-threads) combined with embedded printing in WebComponent mode. When crossOriginIsolated is true (COEP/COOP headers set), WebViewer defaults to wasm-threads backend, which causes intermittent WASM crashes during embedded print.

The error we see is:

RuntimeError: null function or function signature mismatch
at PDFNetThreadedWasm.br.wasm:0x15a338
...
at PDFNetThreadedWasm.worker.js:1:1955

Interestingly, this crash is intermittent - some PDFs print fine, others crash. This aligns with known Emscripten issues around 64-bit integer handling in threaded WASM (ref: emscripten-core/emscripten#17953).

Workaround: Force single-threaded WebAssembly by setting backendType: 'ems' in the constructor:

instance = await WebViewer.WebComponent(
  {
    path: '/pdf-webviewer',
    licenseKey: '...',
    backendType: 'ems',  // Force single-threaded WebAssembly
  },
  viewerElement,
);

// Enable embedded printing for correct page ranges
instance.UI.useEmbeddedPrint(true);

This combination:

  1. Uses single-threaded WebAssembly (avoids threading-related WASM crashes)
  2. Enables embedded printing (fixes the 1-page issue with rasterized printing)
  3. Works reliably in WebComponent mode

Questions for Apryse team:

  1. Is this a known issue with wasm-threads + embedded print in WebComponent mode?
  2. Are there plans to fix the threading issue so we can use wasm-threads with embedded print?
  3. Any performance implications we should be aware of with backendType: 'ems' vs wasm-threads?
6

Hello Wes,

I haven’t been able to reproduce this issue with the following conditions with my React project.

  • WebViewer 11.9
  • Wasm-threads enabled
  • Chrome 143

Is this file specific? Do you have a sample file to help us reproduce this issue?

Is this a known issue with `wasm-threads` + embedded print in WebComponent mode?
I wasn’t able to find this issue in our backlog.

Are there plans to fix the threading issue so we can use `wasm-threads` with embedded print?
If we are able to reproduce this issue, then I can submit a report to the product team where I do expect it to be fixed.

Any performance implications we should be aware of with `backendType: 'ems'` vs `wasm-threads`?
This varies from document to document but the biggest performance gains from using wasm-threads are from loading larger documents.

Best Regards,
Darian