Aborted(Module.asm has been replaced by wasmExports (the initial value can be provided on Module, but after startup the value is only looked for on a local variable of that name))

[samsieber]

This is much like #128; it appears the wasmTable lookup was missed.

Aborted(`Module.asm` has been replaced by `wasmExports` (the initial value can be provided on Module, but after startup the value is only looked for on a local variable of that name))

pdfium-render::initialize_pdfium_render(): Unable to locate wasmTable```

I hacked up the pdfium-lib wasm's js file to be able to load as an ESM module (kinda - I got it working with Vite through some manual modification), and I'm running it a webworker, so I can't even manually patch the window object (since in a web worker the window object doesn't exist).

I have a commit here: samsieber@0846f61; I'd be happy to submit it as a PR if you'd like. I've just noticed you have what seems to be a pretty set pattern of issue, then commit referencing issue.

[ajrcarey]

Hi @samsieber , thank you for reporting the issue.

I cannot reproduce the problem using pdfium-render 0.8.17 and pdfium-lib release 6183 downloaded from https://github.com/paulocoutinhox/pdfium-lib/releases/tag/6183.

Please confirm the version of pdfium-lib you are using, and walk me through the exact steps required to reproduce the problem.

[ajrcarey]

As there have been no further comments and I am unable to reproduce the problem, I will shortly close the issue. Please provide additional comments to keep the issue open.

[ajrcarey]

As there have been no further comments and I am unable to reproduce the problem, I am closing the issue. Please provide the steps required to reproduce the problem before re-opening the issue.

[samsieber]

Sorry for the long delay getting back to you; I was out last week.

I've set up a minimal reproduction here: https://github.com/samsieber/pdfium-render-128-repro . It uses pdfium-render 0.8.17 and pdfium-lib release 6183 downloaded from https://github.com/paulocoutinhox/pdfium-lib/releases/tag/6183, though I did modify it a bit to work with ESM loading (probably the root of the problem). If you have yarn and wasm-pack installed globally, you should be able to clone it, go in and run yarn && yarn wasm && yarn dev to build and run the example. It'll pop up the following screen:

I'm using a bundler, so manually tweaked the pdfium.js file to work with ESM loading, and renamed the wasm file from pdfium.wasm to pdfium_bg.wasm. See this change: samsieber/pdfium-render-128-repro@ff5ed61#diff-97547cdd138a3638f89f726f3a7609dbeca961cf9ac13255a1392f56a0b21fd9 for the exact changes I made. It basically just changed how I imported it, how I fed it the url of the wasm asset, and the name of the wasm asset (to work with my particular wasm loader).

That said, I'd been fine working around it with this nice line window.wasmTable = pdfiumModule.wasmExports.__indirect_function_table;, but I'm now loading it in a webworker, where the window fallback doesn't work (because window is undefined there).

[samsieber]

I've added the reproduction, let me know if you have questions. I'm not sure if you'll see this since it's closed, and I'm not sure how to reopen it, so I'll ping you here @ajrcarey. Also, thanks for maintaining this.

[ajrcarey]

Thank you for the reproduction steps and repo @samsieber , that's very useful. I agree with you that the problem is likely due to the packaging mechanism; I'm not a web developer so I'm reluctant to get too deep into that. I am keen, however, to support all reasonable packaging systems and I'm aware that the build system used in the examples is far from state-of-the-art.

I have made a small change which (I think) addresses the issue in your sample repo, and I have confirmed it doesn't break anything when following the build instructions at https://github.com/ajrcarey/pdfium-render/blob/master/examples/README.md. You can test it by taking pdfium-render as a source dependency in your Cargo.toml file.

[ajrcarey]

As there have been no further comments, and I believe the issue is resolved, I will shortly close the issue. Allowing another three days for feedback from @samsieber .

[samsieber]

This does address the issue. Thanks for your help!

[ajrcarey]

Updated README. Ready to release as part of version 0.8.18.