[Poppler-bugs] [Bug 81760] pdftops sometimes creates huge PS 3 files out of small PDFs

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=81760

--- Comment #19 from Adrian Johnson <ajohnson at redneon.com> ---
(In reply to William Bader from comment #18)
> I have it working. I'm going to clean it up and send patches Sunday night
> after the "taronjada" http://lameva.barcelona.cat/carnaval/ca/taronjada.php
> I made a new FlateEncoder.cc and FlateEncoder.h.
> It can be enabled with ./configure --enable-zlib-compress separately from
> the zlib flate decoder which can still be enabled by --enable-zlib.

I would prefer the options
  --disable-zlib
  --enable-zlib-uncompress

ie default to linking zlib and using it for compression and default to zlib
decompression disabled. zlib is widely available and there is no reason anyone
would not want to use it to reduce PS output size.

> The Flate stream is encoded with ASCII85. Is that necessary? I thought that
> level 2 and higher supported binary data.

I don't think binary is guaranteed to work everywhere. It is better to default
to ASCII and provide an option to enable binary.

> What should the encoder do if deflateInit() returns an error status?

Fallback to LZW.

> I am calling deflateInit with Z_DEFAULT_COMPRESSION. Should the compression
> level be settable?

I don't think a compression level option is necessary. The default works well.

> I used 16K buffers like the deflate stream patch and the zlib examples.
> Should the buffers be larger or configurable?

Unless performance testing shows a larger size is faster I would leave it as
16K.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/poppler-bugs/attachments/20160207/de22f9b1/attachment.html>