Comment 41 for bug 537970

Now I also lifted our laser printer to my office and printed Abschlussarbeit directly through the parallel port. You know what? The logo prints from within Evince.

This indicates that the GNOME print dialog does stuff entirely different from what lpr and gtklp do with remote CUPS servers. In all former cases the same (as in "==", not as in .equals()) remote printer hardware was used. (This was also the very hardware that prints the logo when attached to the parallel port.)

So that means that Evince in Precise prints just fine to a parallel port printer but not to a remote CUPS printer while gtklp and lpr print fine using the same remote CUPS printer that Evince fails to print to.

That lead me to a new hypothesis: the remote CUPS server or one of its subsystems is buggy; printing from gtklp and lpr works because the hardware printer, attached to the CUPS server using Ethernet, is accessed directly from gtklp and lpr while Evince talks to the CUPS server. An experiment (printing a job using Evince and gtklp) refuted this: both jobs appeared in the CUPS job queue.

What's also interesting is that the (failing) remote print job from Evince is listed as 1053k in the Size column in the CUPS jobs list for that printer while the gtklp job clocks in at 989k.

And the absolute super joke is that after reattaching the darn laser printer and killing two stale print processes (hung since March) the bug disappeared and the logo prints correctly out of Evince. This is even more hilarious if you consider that this wasn't the first time we power-cycled the printer and the problems began long before March this year. I'm positive that the PNG printing problem will reappear. Until then I'm not able to repro this any further.