Earlier quoted context omitted.
incompetence
You can read about it here https://pdfa.org/brotli-compression-coming-to-pdf/
That mentions zstd in a weird incomplete sentence, but never compares it.
ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
21–30 of 116 posts
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#22Earlier quoted context omitted.
You can read about it here https://pdfa.org/brotli-compression-coming-to-pdf/
That mentions zstd in a weird incomplete sentence, but never compares it.
They don’t seem to provide a detailed comparison showing how each compression scheme fared at every task, but they do list (some of) their criteria and say they found Brotli the best of the bunch. I can’t tell if that’s a sensible conclusion or not, though. Maybe Brotli did better on code size or memory use?
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#23Earlier quoted context omitted.
You can read about it here https://pdfa.org/brotli-compression-coming-to-pdf/
That mentions zstd in a weird incomplete sentence, but never compares it.
Hey, they did all the work and more, trust them!!!
> Experts in the PDF Association’s PDF TWG undertook theoretical and experimental analysis of these schemes, reviewing decompression speed, compression speed, compression ratio achieved, memory usage, code size, standardisation, IP, interoperability, prototyping, sample file creation, and other due diligence tasks.
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#24Who is responsible for the terrible decision? In the pro vs con analysis, saving 20% size occasionally vs updating ALL pdf libraries/apps/viewers ever built SHOULD be a no-brainer.
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#25Earlier quoted context omitted.
yup, zstd is better. Overall use zstd for pretty much anything that can benefit from a general purpose compression. It's a beyond excellent library, tool, and an algorithm (set of). Brotli w/o a custom dictionary is a weird choice to begin with.
Brotli makes a bit of sense considering this is a static asset; it compresses somewhat more than zstd. This is why brotli is pretty ubiquitous for precompressed static assets on the Web. That said, I personally prefer zstd as well, it's been a great general use lib.
You need to crank up zstd compression level.
zstd is Pareto better than brotli - compresses better and faster
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#26How can iText claim that adding Brotli is not a backward incompatible change (in the "Why keep encoding separate" table)? In the first section the author states that any new feature must work seamlessly with existing readers. New documents created that include this compression would be unintelligible to any reader that only supports Deflate. Am I missing something? Adoption will take a long time if you can't be confi…
It's prototypish work to support it before it land's in the official specification. But it will indeed take some adoption time. Because I'm doing the work to patch in support across different viewers to help adoption grow. And once the big opensource ones ship it pdfjs, poppler, pdfium, adoption can quickly rise.
There are old devices where the viewer can’t be patched.
That’s killing one of the main features of PDF
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#27Why not zstd?
I think this was the main reason (from the linked article) LOL:
"Brotli is a compression algorithm developed by Google."
They have no idea about Zstandard nor ANS/FSE comparing it with LZ77.
Sheer incompetence.
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#28Earlier quoted context omitted.
Brotli makes a bit of sense considering this is a static asset; it compresses somewhat more than zstd. This is why brotli is pretty ubiquitous for precompressed static assets on the Web. That said, I personally prefer zstd as well, it's been a great general use lib.
You need to crank up zstd compression level. zstd is Pareto better than brotli - compresses better and faster
Are you sure? Admittedly I only have 1 PDF in my homedir, but no combination of flags to zstd gets it to match the size of brotli's output on that particular file. Even zstd --long --ultra -22.
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#29tl;dr Commerical entity is paying to have the ISO altered to "legalize" their SDK they are pushing which is incompatible with standard PDF readers. ISO is pay to play so :shrug:
It's not even clear that they were the ones suggesting inclusion. They're just saying their library now supports the new thing. https://pdfa.org/brotli-compression-coming-to-pdf/ > As of March 2025, the current development version of MuPDF now supports reading PDF files with Brotli compression. The source is available from github.com/ArtifexSoftware/mupdf, and will be included as an experimental feature in the upcomi…
Yes, I do not see any source of financial gain that could motivate them for this, because both MuPDF and Ghostscript are free.
MuPDF is an excellent PDF reader, the fastest that I have ever tested. There are plenty of big PDF files where most other readers are annoyingly slow.
It is my default PDF and EPUB reader, except that in very rare cases I encounter PDF files which MuPDF cannot understand, when I use other PDF readers (e.g. Okular).
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#30What is the point of using a generic compression algorithm in a file format? Does this actually get you much over turning on filesystem and transport compression, which can transparently swap the generic algorithm (e.g. my files are already all zstd compressed. HTTP can already negotiate brotli or zstd)? If it's not tuned to the application, it seems like it's better to leave it uncompressed and let the user decide what they want (e.g. people noting tradeoffs with bro vs zstd; let the person who has to live with the tradeoff decide it, not the original file author).