[Pkg-cups-devel] Bug#474241: Bug#474241: Bug#474241: cupsys: Patch for landscape printing from MacOS X clients

[Will Aoki]

On Wed, 30 Apr 2008 at 13:36:23 +0200, Martin Pitt wrote:

> Oh, you mean that the MacOS client have their own cups which
> transforms the PDF into (broken) PostScript and sends this to the
> Debian cups server? Indeed there's not a lot we could do about this
> I'm afraid, since the pdftops filter isn't involved on the Debian
> side.

The MacOS client sends a PDF to the Debian cups server, and the Debian
CUPS server fails to rotate it correctly. This problem doesn't actually
require a MacOS client to reproduce: you can reproduce the problem by
printing a landscape PDF from the command line on a Debian system: the
broken PDF to PostScript converter is on the Debian system.

I reported this problem as #322226, and someone else reported #289893,
which looks like it may be the same problem.

I've been poking at this problem on and off, and the executive summary
is that there are two problems. The first was introduced in 1.2.22-6,
which stopped using the internal xpdf, thus causing a regression of
STR#207. This problem can be fixed using the internal xpdf instead of
the filter script. The pdftops from CUPS 1.4, as provided in the Debian
1.3.6-3 package, has not solved this problem in my testing. I haven't
tried newer Debian packages, nor have I experimented with actually
running CUPS 1.4.

The second problem which affects landscape printing is probably a bug in
Ghostscript (or the way that CUPS drives Ghostscript) and applies to
printers using ljet4, hpijs, and other mechanisms where PostScript
interpreting occurs on the print server, not the printer.

The first part of the problem could be fixed in cups or in poppler-utils
and xpdf-utils. If my understanding of the second problem is correct
(which I'm not entirely confident of), then it needs fixing in cups or
in ghostscript.

For reference, my current production print server is a Sarge system
running cupsys 1.1.23-10sarge1 (using the internal xpdf, as per #322226)
and gs-esp 7.07.1-9sarge1. It does not exhibit either problem.

-- 
William Aoki     KD7YAF    waoki at umnh.utah.edu    5-1924