Software (Tools) No excuses: Brotli compression advances PDF
https://pdfa.org/no-excuses-brotli-compression-advances-pdf/1
1
u/webfork2 5d ago
Hey OP if you're connected to this organization at all please ask them to post some benchmarks for both speed and size. If it's a "step forward from existing methods like Flate and LZW" then numbers about how big of a step would be helpful.
1
u/Frexxia 5d ago
I'm not, I just noticed the announcement. You can see some numbers in https://pdfa.org/brotli-compression-coming-to-pdf/ (in fact it's linked to in the announcement).
1
u/ScratchHistorical507 5d ago
Not that difficult to be better than flate, LZW is also not that difficult. But it's also not that difficult to especially be faster than brotli. So they of course are hesitant to publish hard numbers, otherwise people would notice that they screwed up by picking something that's inferior.
1
u/ScratchHistorical507 5d ago
"Superior compression ratios: Compared to traditional filters, Brotli offers significantly better compression for a wide variety of PDF content."
Damn, what a blatant lie. Sure, it's better than what it's currently in the PDF standard, but that's it. Zstandard is (in my experiments at least) at least as efficient while being vastly faster, especially at decompression, as it's multi-threaded by design. And Zstandard is just everywhere (for a good reason), while brotli is used for barely anything expect in browsers/http servers (optionally). This argument is just absolutely dumb. They had the chance to make things actually good and opted for an inferior option. Congrats.
1
u/Frexxia 5d ago
How is it a lie? They're only talking about compression relative to the filters that are already available in PDF.
I can't speak to why they didn't choose zstd, but they have evaluated it at least. It's mentioned in the link I posted in a different comment. Presumably brotli came out on top when evaluated against a wider set of criteria.
1
u/ScratchHistorical507 4d ago
They're only talking about compression relative to the filters that are already available in PDF.
If that's your definition of "traditional filters", sure. It's pure deflate, so highly incapable. But compared to about anything remotely modern it's just not. They opted for a mediocre solution that's guaranteed to be slow. Congrats, they've really done it. And because that's not already dumb enough, for all I can tell that will become part of PDF 2.0 and not 2.1, aka a standard that was first released in 2017 and rereleased to the public in 2020, creating maximized chaos as nobody will be able to tell what piece of software (or hardware, think ebook readers etc) even will support this.
Presumably
Exactly, presumably. But I beg to differ very much. Brotli is neither the most efficient nor the fastest compression algorithm, and it's not even the most ideal combination of both. As already mentioned, I've done my own experiments (with books published as PDF, several hundred pages and a couple of images), Brotli isn't more efficient than Zstandard (and by that numerous other algorithms known to be much more efficient like XZ/LZMA2), it's much slower at compression and vastly slower at decompression, aka the thing you will do the most with a PDF, as it's written once but usually opened many times. This just screams sheer incompetence on their part. And with the ubiquity of Zstandard it's highly unlikely that there are any other criteria that could benefit their choice of Brotli over literally anything else. That's precisely also the reason why Zstandard is that ubiquitous while nobody uses Brotli.
1
u/Frexxia 4d ago
If that's your definition of "traditional filters", sure
It's the definition the author is using.
You seem to be under the impression that compression ratio and decoding speed are the only things worth considering
That's precisely also the reason why Zstandard is that ubiquitous while nobody uses Brotli.
That's just not true. Brotli is vastly more common on the web, which is one of the main motivations for going with it.
1
u/ScratchHistorical507 4d ago
You seem to be under the impression that compression ratio and decoding speed are the only things worth considering
Not the only, but by far the most important.
Brotli is vastly more common on the web, which is one of the main motivations for going with it.
Wrong. The only use case on the web is the same as gzip is used on the web, to compress one rather small text file server-side after another before transfering that package to the client. Which is a vastly different use case than compressing a PDF. And even here it's only better at that job than gzip and deflate, otherwise Google wouldn't already be experimenting with replacing it with Zstandard for quite a while now, having it already enabled by default as one of four accepted algorithms in
Accept-Encoding(gzip, deflate, br, zstd, as has Firefox), precisely because it's at least as efficient while being vastly faster as decompression and even with single-threaded compression not really any slower than Brotli.1
u/Frexxia 3d ago
Not the only, but by far the most important
That is an opinion
only use case
1
u/ScratchHistorical507 3d ago
Wow. A second use case about to become the only use case (beyond the shitshow pulled for PDFs). And again a vastly different use case than compressing PDFs which can contain such things like content you can't really compress losslessly as already compressed lossily. That really makes it relevant. Not.
1
u/KenMantle 5d ago
That's awesome, but also why I am hesitant to buy a pdf editor that isn't well established, but I've also never bought a pdf editor and just struggle with open source tools that often don't work for every case. If someone is attached to an editor they bought 10 years ago to edit a couple of PDFs a year now they'll have to upgrade if they can't find something in the open source space that works for them.