consider to swap to mupdfjs ?

[panaC]

It seems there is a new lib in the town :) mupdf-js

• wasm
• c library well supported
• no need to web render pdf to get the cover img
• fast
• no viewer built-in, we have to create one specific to our needs

https://www.mupdf.com/

used in sumatrapdf

[danielweck]

PDF.js may be a slower rendering engine, but it is a mature library, maintained / supported by many developers, with a strong feature set (including text selection + annotations) and a page layout logic that integrates quite well in Thorium.
I am not sure that the end-user benefits of a faster / lighter PDF rendering engine outweigh the risk of integration problems when adding WASM in Thorium's Electron stack. By the way, is the WASM library portable (i.e. identical binary) for all supported platforms: Linux, Windows, Mac in Intel and ARM target matrix?

[danielweck]

...perhaps a useful Proof Of Concept would be to reimplement the cover image extractor?
Minimum impact, easy to revert if we discover integration problems in one of our production builds for some target platforms?

[panaC]

...perhaps a useful Proof Of Concept would be to reimplement the cover image extractor? Minimum impact, easy to revert if we discover integration problems in one of our production builds for some target platforms?

This is my main target for the moment, indeed

[panaC]

We need to discuss the pros and cons, cost/benefit ratio of pdf-js and mupdf, I think.

At the moment, pdf-js with a large pdf file like Intel x86 manual (5082 pages) is extremely slow and barely usable with the chrome UI. Also the bottom bar (navigation) is broken (#1340).

#2670