8 ms·
MuPDF WASM Viewer Demo
- cess11 3y agoThat's pretty neat. I could use something like this professionally, might actually to 'contact sales' and see what kind of money they expect.
- wwarner 3y agoI tried paying for muPDF a few years ago and it was way way more than my company could afford. Had to use a different system that was not dual licensed.
- reaperman 3y agoWhat is your application? I'm curious why AGPL wouldn't be a reasonable choice. Seems like you could modify it and link it in a way that doesn't trigger AGPL on anything except your modifications to MuPDF itself, which don't seem like they'd be too valuable to give away in most cases.
- wwarner 3y agoWhat is the point of a dual license if you can't pay for the commercial rights which guarantee that you're not infringing on the copyleft license? Whoever I spoke to at Artifex [0] several years ago told me the terms of the commercial license were that if any output of muPDF were visible to the public, my company would owe $10k/mo plus some share of the revenue of the company. Unlimited internal use fell under the AGPL and was therefore free. Btw, the software is incredible, it was a shame I couldn't use it! [0] https://mupdf.com/licensing/index.html#commercial https://mupdf.com/licensing/index.html#commercial
- cess11 3y agoI'm in two markets, both heavily reliant on PDF rendering, viewing and distribution. Commonly PDF/A, which isn't very popular so having to adapt libraries happens every now and then. We're both into desktop applications and network services. While I'm quite FOSS positive, a lot around GPL style licensing hasn't been tested in court and I don't want to be a pioneer in this area. Besides the business aspects of having to maybe publish some of the 'secret sauce', of course.
- merb 3y agoThe last time I contacted them. The money was not my problem. However the problem was that the license used a fork instead of the open source code, which meant we needed to use binaries from artifex which was exactly what we wanted to avoid.
- keepamovin 3y agoThis has excellent performance, and is incredibly fast. Well done! Mutools is fantastic for PDF I use it as a backup converter when imagemagick fails in my document viewer: https://github.com/dosyago/chai https://github.com/dosyago/chai
- adrian_b 3y agoIndeed, this appears to have the same advantage over other viewers as the standalone MuPDF, i.e. much greater rendering and navigating speed. MuPDF is my main PDF viewer, due to its unmatched performance and good full-screen UX, even if I sometimes encounter PDF files that cannot be rendered by MuPDF, when I have to fall back to other viewers, e.g. Okular.
- keepamovin 3y agoComing from someone who is clearly in academia / research adjacent (!! judging by your comments) this is high praise!! PDFs are close to currency of the realm. Haha! :)
- Modified3019 3y agoThe developers of muPDF would likely be interested in the files that are rendered incorrectly so that can be fixed
- bramhaag 3y ago[flagged]
- keepamovin 3y agoHahaha! :) Which words would you have used a thesaurus for? I don't see anything that complex there.
- leononame 3y agoThe performance is astonishing. On my underpowered android, the PDF was super smooth. It's miles ahead of other PDF viewers (the worst offender is the Google Docs in browser pdf viewer, it's just horrible on my phone to a point where I refuse to even look at those documents on my phone). Really impressive
- rtcode_io 3y ago[flagged]
- bramhaag 3y ago> They don't have a permissive license Good > and are generally very rude. Any examples of this?
- rtcode_io 3y agoI updated my original comment.
- deleted 3y ago[deleted]
- skywhopper 3y agoYeah, people who are rude, condescending, and uptight about licensing are a real drag, huh?
- rtcode_io 3y agoI was not using Mu anything anywhere! I was looking for a WASM renderer (then found PDFium and helped with its compilation). The dev just assumed I might be and replied to me as if I were 5 and deserved scolding o_O.
- rtcode_io 3y agoMy brief involvement in PDFium WASM builds: https://github.com/paulocoutinhox/pdfium-lib/issues?q=is%3Aissue+author%3A%40me+ https://github.com/paulocoutinhox/pdfium-lib/issues?q=is%3Ai...
- gschizas 3y agoJust letting you know, your link is incorrect (you put author:@me instead of your actual username)
- odmttelugu 3y ago[flagged]
- jonkoops 3y ago[flagged]
- bebnel 3y agoTried this on Firefox for Android but the table of contents takes up half the screen width ways, and I couldn't figure out how to get rid of it. Plus, it froze the browser when I backed out of the page. Also it's quite slow to load the WASM, about five seconds before it starts processing the PDF. This is on a fairly recent mid-range Samsung phone (Galaxy A52s 5G). Edit: turns out it's View -> Outline to remove the contents pane. There's no "fit to page" option so I still couldn't see the whole page - the 50% zoom out option wasn't sufficient to see everything corner to corner.
- SiempreViernes 3y agoYeah, it needs a "fit page" option. But as a first example its very impressive.
- Da5idBlackSun 3y agoYou can get rid of it by clicking outline in the menu. Then it works surprisingly fast!
- vegetable 3y ago[dead]
- Olesya000 3y ago[dead]
- Olesya000 3y ago[dead]
- pama 3y agoFYI: This does not work with iPhone lockdown mode.
- ttul 3y agoA WASM-based PDF viewer may have security advantages over a native PDF viewer such as the viewer embedded in Safari or Chrome. I wonder if anyone has put MuPDF into a browser extension?
- kevincox 3y agoIIRC Chrome's PDF viewer is built upon NaCl which is basically a precursor to WASM. So it has lots of the same benefits and is basically running inside the web sandbox already. Until Firefox shipped PDF.js it was likely the most secure widely used PDF viewer due to this layered architecture. Of course NaCl is no longer available to web clients, so I don't know what the exact state of the Chromium PDF viewer is. Is NaCl maintained just for it or is it using some other sandbox now?
- kevingadd 3y agoAccording to https://blog.chromium.org/2024/02/optimizing-safe-browsing-checks-in.html https://blog.chromium.org/2024/02/optimizing-safe-browsing-c... the PDF viewer is still sandboxed, which would suggest they're either still using NaCl or they've moved to WASM.
- khimaros 3y ago"Leading MuPDF.js" indefinitely on Mull for Android (installed from F-Droid)
- _rdvw 3y agoMy Mull disables WASM by default, please see the documented workarounds here: https://divestos.org/pages/broken#mull https://divestos.org/pages/broken#mull
- btown 3y agoVery cool! But this being AGPL has me wonder: if you as a user download an AGPL licensed WASM binary, because the browser is making network connections by design, are you required to share the source with any third party your browser makes any request to? And if your browser has proprietary/not “generally available” compiled/minified code loaded, from Widevine to your corporate Chrome extension, are you in violation of AGPL if you don’t share all the sources to all those things, which by law you cannot have? Not a lawyer, but the idea of AGPL WASM blobs gives me shivers.
- graemep 3y ago> Very cool! But this being AGPL has me wonder: if you as a user download an AGPL licensed WASM binary, because the browser is making network connections by design, are you required to share the source with any third party your browser makes any request to? No. Clearly not. A browser making connections to servers is not the same as a "user interacting with it remotely". > And if your browser has proprietary/not “generally available” compiled/minified code loaded, from Widevine to your corporate Chrome extension, are you in violation of AGPL if you don’t share all the sources to all those things, which by law you cannot have? Only if you distributed the browser with AGPL code in it. If just runs WASM code its no different from any interpreter running GPL code.
- pessimizer 3y ago> are you required to share the source with any third party your browser makes any request to? The source to your changes to the binary, you mean, maybe? I don't understand the question. You seem to be implying that using an AGPL WASM binary would require you to share the browser's source. If that binary were a network application that was serving other clients, it makes sense to me that you'd be required to share modifications that you made to that binary, but I have no idea of how you would include the entire browser in that calculation. If there's anything scary, I'd say it would be that if you were serving a WASM blob to someone's browser, you'd have to be prepared to also distribute the source (and changes) to the binary if it was AGPL licensed.
- p4bl0 3y agoI'm sure it's not on purpose, but that sounds like fear-mongering against the AGPL license. None of the concerns raised here are remotely true. No worries :).
- MaxLeiter 3y agoVery cool project. I noticed in the dependencies section its using its own JS interpreter: https://mujs.com/ https://mujs.com/
- solardev 3y agoIs there no mobile view? The sidebar stays open and the page width can't be shrunken with a pinch to zoom.
- lofaszvanitt 3y agoIt has issues rendering the CIS_Ubuntu_Linux_22.04_LTS_Benchmark_v1.0.0 file. Lags like hell, it's ok with other files.
- felipefar 3y agoBesides opening PDFs (and despite the project's name), MuPDF can also read EPUBs, but currently this WASM viewer can't open them. They must have had to reduce functionality of the library to port faster to WASM. But I wonder if there are any intrinsic issues with displaying EPUBs using WASM?
- woodson 3y agoSince EPUBs are just zipped HTML files, I guess rendering can be done more efficiently by the browser itself rather than by custom rendering on an HTML canvas.
- felipefar 3y agoYou're right. In that case you could implement the unzipping and metadata parsing in WASM and just hand the HTML to the browser to be rendered. It's still useful since browsers don't come with built-in EPUB support.
- ffsm8 3y agoI wrote an epub reader a few years ago and this is false. most epubs are just zipped html, but not all. There are different versions to this file format and some need to be parsed as xml. The chapter files will mostly adhere to html with caveats wrt anchor tags, image sources and similar as well as metadata wont be parsed/work with html parsers.
- felipefar 3y agoCan't you preprocess them with a custom parser and then hand over a conformant HTML to the browser?
- ffsm8 3y agoYes, but while thatd be a lot easier for epub (vs PDF), you can fundamentally do that for any other format too. You could even - technically - take a picture as an input and then render it via background color rgb() using divs pixel-by-pixel. thatd still fall under that description.
- tuananh 3y agotried this on firefox (v125) and got this error in console CompileError: at offset 0: failed to match magic number
- filmor 3y agoIf webOS came out with WASM already in place, it would have been even better :) When the Touchpad was firesaled, I got one and was disappointed with the PDF viewer. Because there was no such thing as WASM (or even asm.js) at the time, it used out of the box a service provided by Adobe that on request from the UI rendered tiles of the PDF at different resolutions, depending on the zoom level. Since the frontend code was JS, it was easy to implement an alternative via mupdf (https://github.com/filmor/webos-pdf/blob/master/arxservice.cpp https://github.com/filmor/webos-pdf/blob/master/arxservice.c...). Via the same inefficient process (rendering png tiles onto the filesystem), the mupdf implementation was about 3 times faster than the original (though, it's been 13 years, the actual speedup might have been less :)).