[HN Gopher] MuPDF WASM Viewer Demo
___________________________________________________________________
MuPDF WASM Viewer Demo
Author : aragonite
Score : 247 points
Date : 2024-04-20 09:52 UTC (13 hours ago)
(HTM) web link (mupdf.com)
(TXT) w3m dump (mupdf.com)
| keepamovin wrote:
| This 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
| adrian_b wrote:
| Indeed, 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 wrote:
| Coming 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 wrote:
| The developers of muPDF would likely be interested in the
| files that are rendered incorrectly so that can be fixed
| leononame wrote:
| The 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
| hatch_q wrote:
| I don't see it having any better performance than integrated
| chrome pdf viewer. Furthermore, with it using wasm i'd expected
| it to have custom renderer, but it's just pdf to html
| converter.
|
| And loading times are quite bad (10 times slower - compared to
| firefox or chrome pdf viewers).
| keepamovin wrote:
| Loading the mupdf.js bundle is slow right now. When I checked
| it out it was super fast. Guess it's a
| server/ratelimit/caching issue with the HN hug being top of
| front page.
|
| Which is what I guess you mean about 10x slower -- so you're
| making an unfair comparison as you're counting the network at
| peak, whereas browser plugins load from disk or memory.
|
| But I actually thought the load of the PDF (once the app was
| loaded) was, for MuPDF.js, slightly _faster_ than the browser
| plugin. When I watched it, tho I have not benched it. Do you
| have any benchmarks?
| CryZe wrote:
| It uses a custom renderer, which seems to just blit its image
| data onto a canvas. The HTML is just there so you can
| actually select the text.
| dsp_person wrote:
| Does this generally satisfy accessibility needs too?
| SiempreViernes wrote:
| I downloaded this file https://indico.cta-
| observatory.org/event/5245/contributions/... and tried timing
| how long it took for the standard firefox vs this MuPDF
| viewer to render the first slide and there is like at least 3
| second difference.
|
| As others in the thread also report significant speed gains I
| think you either have some weird issue with your setup or how
| you measure performance.
| supernes wrote:
| This WASM "demo" is literally the only viewer on Windows I've
| found that can handle documents like the Baldur's Gate 3
| Artbook (around 300MB of high-res artworks in PDF format).
| Native and browser-based viewers all choke even on a decent
| system with lots of memory.
| remram wrote:
| Even the MuPDF native app fails?
| sebras wrote:
| If that is indeed the case, we'd appreciate a bug report
| over at https://bugs.ghostscript.com It is hard to fix
| issues we don't know about. :)
| Modified3019 wrote:
| I'm curious, have you tried SumatraPDF (uses muPDF under the
| hood)?
|
| https://github.com/sumatrapdfreader/sumatrapdf
| hn_acker wrote:
| Off-topic: Chai's license seems to be proprietary now. 7 months
| ago the license was AGPL as given by the LICENSE and README.md
| files [1][2]. 1 month ago, the LICENSE file was changed to the
| text of the PolyForm Noncommercial License 1.0.0 [3], but the
| README.md still says AGPL. If Chai continues to use MuPDF (AGPL
| [4]), then isn't Chai's new license contradictory (unless the
| Chai developers got a license exception from Artifex Software)?
|
| [1]
| https://github.com/dosyago/chai/blob/a6b7fb50647ae001185bdc8...
|
| [2]
| https://github.com/dosyago/chai/blob/a6b7fb50647ae001185bdc8...
|
| [3]
| https://github.com/dosyago/chai/commit/45da5f12ab8a817dc4f74...
|
| [4]
| https://github.com/ArtifexSoftware/mupdf/blob/master/COPYING
| bebnel wrote:
| Tried 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.
| Da5idBlackSun wrote:
| You can get rid of it by clicking outline in the menu. Then it
| works surprisingly fast!
| SiempreViernes wrote:
| Yeah, it needs a "fit page" option. But as a first example its
| very impressive.
| cess11 wrote:
| That's pretty neat. I could use something like this
| professionally, might actually to 'contact sales' and see what
| kind of money they expect.
| wwarner wrote:
| I 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 wrote:
| What 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 wrote:
| What 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
| reaperman wrote:
| Okay reading all of that link, in totality it's getting
| fairly ridiculous.
| cess11 wrote:
| Thanks for sharing. That's kinda pricey, in the vicinity of
| 1-2 employees.
| cess11 wrote:
| I'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.
| pama wrote:
| FYI: This does not work with iPhone lockdown mode.
| solardev wrote:
| What is iPhone lockdown mode?
| ttul wrote:
| A 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 wrote:
| IIRC 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?
| khimaros wrote:
| "Leading MuPDF.js" indefinitely on Mull for Android (installed
| from F-Droid)
| btown wrote:
| 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?
|
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| I'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 wrote:
| Very cool project. I noticed in the dependencies section its
| using its own JS interpreter: https://mujs.com/
| solardev wrote:
| Is there no mobile view? The sidebar stays open and the page
| width can't be shrunken with a pinch to zoom.
___________________________________________________________________
(page generated 2024-04-20 23:00 UTC)