[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 #20 from William Bader <williambader at hotmail.com> ---
>I would prefer the options --disable-zlib --enable-zlib-uncompress

OK. I saw that is what your patches did, but I wanted to make the minimum
amount of changes to the build system.

I think that your patches worked so --disable-zlib also disabled zlib
uncompression. Is it OK to tie them together, or is it possible that someone
would want zlib uncompression and not zlib compression?

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

I used level1sep a lot, but to make files that I can software-separate and not
because I have a level 1 RIP. I already made a -binary options to make those
files smaller. Could -binary also skip the ascii encoding in level 2 and 3?

>Fallback to LZW.

What is the best way to do that? Can the FlateEncoder constructor return an
LZWEncoder, or does it need to return an error flag, and then all the places in
PSOutputDev need to check the status? That could get messy.

FlateEncoder also has a reset() function that needs to call deflateEnd() and
deflateInit(). At that point, I think that it would be very hard to recover.

I looked at deflate.c in the zlib source. I think that deflateInit() can fail
only from a failed memory allocation, so it is probably very unlikely to fail,
and if it does fail, probably other parts of poppler are going to fail for the
same reason of lack of memory.

Regards, William

-- 
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/427e915a/attachment-0001.html>