Wouldn't lzma2 be better here since a pdf is more read heavy?
ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
11–20 of 116 posts
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#12How 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.
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#13Some real cognitive dissonance in this article… “The PDF Association operates under a strict principle—any new feature must work seamlessly with existing readers” followed by introducing compression as a breaking change in the same paragraph. All this for brotli… on a read-many format like pdf zstd’s decompression speed is a much better fit.
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.
This bizzare move has all the hallmarks of embrace-extend-extinguish rather than technical excellence
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#14Why not zstd?
incompetence
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#15tl;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:
No this feature is coming straight from the PDF association itself and we just added experimental support before it's officially in the spec to help testing between different sdk processors.
So your comment is a falsehood
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#16Wouldn't lzma2 be better here since a pdf is more read heavy?
Going by one of Brotli’s authors’ comment [1] on another post, it probably wouldn’t.
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#17Some real cognitive dissonance in this article… “The PDF Association operates under a strict principle—any new feature must work seamlessly with existing readers” followed by introducing compression as a breaking change in the same paragraph. All this for brotli… on a read-many format like pdf zstd’s decompression speed is a much better fit.
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.
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#18Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#19Why not zstd?
incompetence
You can read about it here https://pdfa.org/brotli-compression-coming-to-pdf/
Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss
#20Are they using a custom dictionary with Brotli designed for PDFs? I am not sure if it would help or not, but it seems like one of those cases it may help? Something like this: https://developer.chrome.com/blog/shared-dictionary-compress... In my applications, in the area of 3D, I've been moving away from Brotli because it is just so slow for large files. I prefer zstd, because it is like 10x faster for both compressi…
The pdf association is still running experiments on whether or not to support custom dictionaries based on real life workloads gains.
So it might land in the spec once it has proven if offers enough value