pdftops loses grid lines

The following bug is being reported upstream on behalf of the OP.
Originally posted here: https://bugs.launchpad.net/bugs/604724

We discovered that cups in lucid does not correctly print certain PDFs when printing from the command line with lpr or as a shared printer from preview in OS X. The same file prints correctly with cups on hardy. This issue occurs with a variety of different printers.

I tracked down the problem to /usr/bin/pdftops by running the pdf through the filters that cups does according to the log. /usr/bin/pdftops is called by the cpdftocps filter.

This pdftops is installed from poppler-utils:
$dpkg-query -S /usr/bin/pdftops
poppler-utils: /usr/bin/pdftops

After running the pdf through each step of the filter, I opened it with evince. After running through pdftops, evince showed exactly what I see when I print the file.

Interestingly, if I print from evince or acroread, all the lines are printed correctly. I think they are converting the file to postscript themselves before sending it to cups.

I will attach the file that shows this behavior.

The pdftops provided by the cups package does not exhibit this problem.
$ dpkg-query -S /usr/lib/cups/filter/pdftops
cups: /usr/lib/cups/filter/pdftops

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: poppler-utils 0.12.4-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.32-23.37-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-23-generic x86_64
Architecture: amd64
Date: Mon Jul 12 12:33:43 2010
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: poppler

You forgot to attach the file

Hi Albert,

The example you are requesting can be found here:
http://launchpadlibrarian.net/51793787/f10test.pdf

What does "CancelOk" mean?

If i run pdftops f10test.pdf and then open the resulting f10test.ps with gs i correctly see grid lines, don't you?

(In reply to comment #3)
> What does "CancelOk" mean?
>

I don't know where you saw that.

> If i run pdftops f10test.pdf and then open the resulting f10test.ps with gs i
> correctly see grid lines, don't you?

No, I do not see all of the grid lines when I open the file with gs. There should be a horizontal grid line between every "xxxx".

It is interesting to note that at different zoom levels, different lines appear and disappear. Maybe you found the right size where all of the lines appear. When printed, it looks the way evince displays it at 100%.

I have pdftops version 0.12.4 and gs version GPL Ghostscript 8.71.

I just realized that I have not tested this on a 32 bit system. This may be a 64 bit bug.

I don't have any 32bit lucid systems installed right now.

CancelOk is on the subject of the bug.

If the lines show up randomly depending on the zoom level, i'd say it's partly fault part of the renderer (i.e. the printer or gs) for not rendering them at all levels, of course we could create PS in a different (since PS is a touring complete langauge) way to make sure "it works" but i expect this to be difficult and my level of PS knowledge is very small so patches are welcome.

(In reply to comment #5)
> I just realized that I have not tested this on a 32 bit system. This may be a
> 64 bit bug.
>
> I don't have any 32bit lucid systems installed right now.

This is a problem on both 32 bit and 64 bit systems.

I discovered that the bug did not exist in pdftops version 0.10.5 on jaunty.

This bug also doesn't exist in xpdf's pdftops.

Can someone git bisect the issue and find the code change that introduced the problem?

I have a friend that says the bug was introduced by 572779f8037763c1e0ee64c47a3dad6df0d3b693..b97591672e0d9c31a3d044fe52e34cc80a491221

Can anyone confirm?

I hate when people play with the priorities *us* developers have to set, this only lowers the priority i'll give to your bug, so next time be a good boy and don't set it to blocker when obviously it is not

(In reply to comment #11)
> I hate when people play with the priorities *us* developers have to set, this
> only lowers the priority i'll give to your bug, so next time be a good boy and
> don't set it to blocker when obviously it is not

I would like to point out that I am the original reporter of this issue and that it wasn't me that messed with your priority. Please don't lower your priority over my issue because someone else messed with it.

Thank you.

-- 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/604.