Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

pdfa.org

Post reply on HN
Print view View original

31–40 of 116 posts

Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

#33

Post by atiedebee »

dist-epoch wrote: post #25
adzm wrote: post #17

Earlier 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

I thought the same, so I ran brotli and zstd on some PDFs I had laying around.

  brotli 1.0.7 args: -q 11 -w 24
  zstd v1.5.0  args: --ultra -22 --long=31 
                 | Original | zstd    | brotli
  RandomBook.pdf | 15M      | 4.6M    | 4.5M
  Invoice.pdf    | 19.3K    | 16.3K   | 16.1K
I made a table because I wanted to test more files, but almost all PDFs I downloaded/had stored locally were already compressed and I couldn't quickly find a way to decompress them.

Brotli seemed to have a very slight edge over zstd, even on the larger pdf, which I did not expect.

Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

#34

Post by dchest »

dist-epoch wrote: post #25
adzm wrote: post #17

Earlier 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

Not with small files.

Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

#35

Post by DetroitThrow »

dist-epoch wrote: post #25
adzm wrote: post #17

Earlier 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

I love zstd but this isn't necessarily true.

Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

#36

Post by eru »

ndriscoll wrote: post #30

What 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 w…

Well, if sanity had prevailed, we would have likely stuck to .ps.gz (or you favourite compression format), instead of ending up with PDF.

Though we might still want to restrict the subset of PostScript that we allow. The full language might be a bit too general to take from untrusted third parties.

Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

#38

Post by order-matters »

atiedebee wrote: post #33
dist-epoch wrote: post #25

Earlier quoted context omitted.

You need to crank up zstd compression level. zstd is Pareto better than brotli - compresses better and faster

I thought the same, so I ran brotli and zstd on some PDFs I had laying around. brotli 1.0.7 args: -q 11 -w 24 zstd v1.5.0 args: --ultra -22 --long=31 | Original | zstd | brotli RandomBook.pdf | 15M | 4.6M | 4.5M Invoice.pdf | 19.3K | 16.3K | 16.1K I made a table because I wanted to test more files, but almost all PDFs I downloaded/had stored locally were already compressed and I couldn't quickly find a way to decompr…

Whats the assumption we can potentially target as reason for the counter-intuitive result?

that data in pdf files are noisy and zstd should perform better on noisy files?

Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

#39

Post by jeffbee »

order-matters wrote: post #38
atiedebee wrote: post #33

Earlier quoted context omitted.

I thought the same, so I ran brotli and zstd on some PDFs I had laying around. brotli 1.0.7 args: -q 11 -w 24 zstd v1.5.0 args: --ultra -22 --long=31 | Original | zstd | brotli RandomBook.pdf | 15M | 4.6M | 4.5M Invoice.pdf | 19.3K | 16.3K | 16.1K I made a table because I wanted to test more files, but almost all PDFs I downloaded/had stored locally were already compressed and I couldn't quickly find a way to decompr…

Whats the assumption we can potentially target as reason for the counter-intuitive result? that data in pdf files are noisy and zstd should perform better on noisy files?

What's counter-intuitive about this outcome?

Re: ISO PDF spec is getting Brotli – ~20 % smaller documents with no quality loss

#40

Post by Someone »

ndriscoll wrote: post #30

What 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 w…

- inside the file, the compressor can be varied according to the file content. For example, images can use jpeg, but that isn’t useful for compressing text

- when jumping from page to page, you won’t have to decompress the entire file

Post reply on HN