Andrew Hall

Hey @rybon , this is likely because the in-memory representation of the PDF page exceeds the memory allocated to the WASM worker. This limit varies depending the JS engine, see...

@rybon I've added an automated test suite on [this branch](https://github.com/andytango/mupdf-js/tree/testing/specs). In it, I've tested the entire API and in particular ran `getPageText` with your example file, but this hasn't caused...

Thanks @bfarmilo ! I'll see if I can reproduce the issue on different architectures and node versions using cloud services. It looks like WASM's promise of portability has some caveats...

@rybon Great to hear that you managed to get it working. ~~Would you mind letting me know what the minor tweaks were that you made to the build step? Or...

@rybon > I managed to resolve all these issues by reusing the build setup of this repo with some minor tweaks and compiling to WASM from the mupdf source code...

Hey @rybon, could you please provide repro steps, including: - the example file - the search query you used - the page number that this behaviour is observed on? Thanks!...

Thanks @anthrax63 - I will review these changes and merge next week

@mohammedsahl and @m59peacemaker - thank you very much for your work on this! I will review the PR and take a look at the failing test case next week

@stylesuxx Sure, so provide instructions and examples on how to do this that people could paste into their package.json if they wish?

Hey, I'm not sure I agree that it's essential. I use redux-saga, and at a pinch you could get away with just using promises and closures. I have thought of...