-
chai
chai - Experience Zero Trust security with Chai! Convert and view documents as vivid images right in your browser. No mandatory downloads, no hassle—just pure, joyful security! 🌈 (by dosyago)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
jbig2dec
This is a mirror: the canonical repo is: git.ghostscript.com/jbig2dec.git. This repo does not host releases, they are here: https://github.com/ArtifexSoftware/jbig2dec/tags
-
But not just off-topic: abusive, and dishonest.
I'm not sure this even applies as we call the mutool binary installed via apt, rather than use or modify their libraries.
Even if it applies, Mu's AGPL requires you release the source code, which is what we already and have always done. So it doesn't apply. It doesn't require you use a particular license.
As you're so keen on searching our source you could have also easily read what the AGPL means, and seen that we use mutool^0, which I guess you would have done, if you were actually intending to be helpful rather than just trying to make us look bad, right? Hahaha! :)
I guess you're one of those people bitter at our success or maybe you were trying to use BrowserBox without paying the licensing fees and you didn't like that we made it commercial, is that right? Hahaha! :)
It seems if you were genuinely trying to be helpful rather than dishonest and trying to make us look bad, you would have just emailed me, right? Hahahahaha! :)
https://github.com/dosyago/chai/blob/37c1a1ec0941d81e0d6f8af...
I am letting people know of permissive alternatives (https://github.com/paulocoutinhox/pdfium-lib) and their usage in web components (PDFium.wasm + PDF.js).
My comment also serves as a promise to open-source my components under the same permissive license.
I don't want people exposed to unnecessary stress.
Very cool project. I noticed in the dependencies section its using its own equally-impressive JS interpreter: https://mujs.com/
I still haven't found an tolerably fast PDF reader, and I'm permanently miserable with that file format. The example in OP works great, but that's only an "easy, modern" PDF made up of text. There's still nothing adequate (mupdf/mutool included) for the common case of scanned-page PDF's.
The root problem isn't an easy performance fix: it's that a very popular PDF image compression format, JBIG2 [0], is unlike modern formats slow in decompression as well as compression. Here's the decompress hot loop [1,2] from libjbig2dec.so, which MuPDF calls out to. I isn't thread- or SIMD- parallelized, and I suspect that it isn't possible at all. There's just no easy way forwards in the near future—other than "buy faster CPU's".
[0] https://en.wikipedia.org/wiki/JBIG2
[1] https://github.com/ArtifexSoftware/jbig2dec/blob/master/jbig...
[2] https://github.com/ArtifexSoftware/jbig2dec/blob/master/jbig...
I’m curious, have you tried SumatraPDF (uses muPDF under the hood)?
https://github.com/sumatrapdfreader/sumatrapdf
If 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.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 :)).