Created attachment 25833 [details] Sample Chart created with BIRT 2_3_1. When running pdftops on the attached small PDF file (4K), the result Postscript file is 560K. Trying to manipulate the program with command line arguments (level3, ...), did not yield any improvement. With XPDF 3.0, the PS file size is <20K. It seems that the code attempt to convert the small chart into high res image, resulting in loss of precision, large file, and long printing/viewing time. The PDF file was generated with BIRT - Ecplise Reporting platform. I'm build/run poppler or RedHat 4
My tests: poppler produces a 547K file that sort of works xpdf 3.02 produces a 547K file that crashes gs xpdf 3.01 produces a 21K file that has the wrong backround color (black) Can't test xpdf 3.0 since the tarball seems not to be online anymore. So yeah it could be better, but not a huge pressing bug in my book, feel free to send patches to improve behaviour, otherwise while it's on my todo list it's quite low on it so it probably means *i* will never get time to fix it.
Hi, We have been using xpdf for few years to convert PDF to PS (most recently on RH4). I will be happy to take a look if you can send me some pointers on where to start. In particular: - Is is true that the file size is much larger because the image get rendered at (at high resolution) into an image ? - Any idea which source file(s) I should be looking. - I have the RH4 tar ball sources (from ftp.redhat.com). I've tried solving the background problem (as a short term solution, since RH5 does not include xpdf) at all. Any idea how where to start on the background problem will be appreciated. - Which solution you think will work better: reducing the image size (with LZW or ZLIB compression), or switching to vector graphics (like xpdf 3.0) ? I would bet on the vector graphics. FYI, As a short term solution, we explictly set the chart background to WHITE (in BIRT), which allow us to get a small PS (using xpdf 3.0) with the right background.
Just comment on my previous note. I've realized that BIRT deliver the chart as an image (in this case, it almost 1000x360 pixels) - which the PDF file store in compress format). So that only option is to work on compressing the postscript images (taking advantage of level3 or level2). Is it possible to use the compressed PDF image in the PS output. This may save processing time ? Yair
Doubt you can reuse the image, even Adobe gets 183K on printing that file. The solution would be printing a /LZWDecode image like adobe does but that's using the GIF patents so it's something we will have to think how to accept. The file responsible for converting to PS is PSOutputDev.
(In reply to comment #4) > Doubt you can reuse the image, even Adobe gets 183K on printing that file. The > solution would be printing a /LZWDecode image like adobe does but that's using > the GIF patents so it's something we will have to think how to accept. > > The file responsible for converting to PS is PSOutputDev. > LZW patents has expired in 2003. (Per http://en.wikipedia.org/wiki/Lempel-Ziv-Welch). Should not be an issue. In any case, postscript level 3 has deflate compression ("zlib") - which provide better compression.
Go for it :-)
Decreasing importance, it is a bug yes, but not worst than the average bug.
(In reply to comment #7) > Decreasing importance, it is a bug yes, but not worst than the average bug. In case only the increased file size is annoying, it is not that worse. But afaik this is also the reason that some PDFs (most of the ones I want to print, that I generate using latex) are printed in a reduced quality, because cups uses poppler to create the PS from PDF. I created a bug about this in Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=574118 And this is a regression compared to the old version that is used in RHEL 5.
Till, Why would filesize matter regarding printing quality?
Sorry for the late reply, I forgot to add myself to the CC list. I am used to getting on the CC list by default from Red Hat Bugzilla. (In reply to comment #9) > Till, Why would filesize matter regarding printing quality? It is not the filesize per se, but the pre rendering afaik. It results in a worse printout. Maybe the resolution for the rendering is less compared to when the printer renders the page. But afaics there is no option to specify a resolution.
(In reply to comment #10) > It is not the filesize per se, but the pre rendering afaik. It results in a > worse printout. Maybe the resolution for the rendering is less compared to when > the printer renders the page. But afaics there is no option to specify a > resolution. I just retried with #define splashDPI 600 instead of 300 in poppler-0.12.4/poppler/PSOutputDev.cc and now the printing quality is similiar to the old CentOS version, but still worse.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/537.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.