[cups.general] Problem printing pdf document

[Helge Blischke]

Johannes Meixner wrote:
> Hello,
> 
> On Sep 7 08:50 Helge Blischke wrote (shortened):
> 
>>Franz Pfoertsch wrote:
>>
>>>Johannes Meixner wrote:
>>>
>>>
>>>>Note that when Ghostscript fails to process it, it is very likely
>>>>a broken PDF. Use for example "gs -sDEVICE=x11 -r60 file.pdf"
>>>>to display it ([Enter] for next page, [Ctrl]+[C] to quit)
>>>>and note if there appear Ghostscript error messages.
>>>
>>>This breaks 
>>>gs -sDEVICE=x11 -r60 beleg.pdf
>>>ESP Ghostscript 8.15 (2005-09-22)
>>>Copyright (C) 2004 artofcode LLC, Benicia, CA.  All rights reserved.
>>>This software comes with NO WARRANTY: see the file COPYING for details.
>>>Processing pages 1 through 1.
>>>Page 1
>>>   **** Warning: Embedded symbolic TT fonts must contain a cmap for
>>>Platform=1 Encoding=0.
>>>Error: /invalidfont in --show--
>>>Operand stack:
>>>   --dict:5/5(L)--
>>>
>>>I made some more test with pswrite on SLES9 GS 7.07 and it worked!
>>
>>I suspect the error is due to differently implemented TT rasterisers.
>>The Adobe Type42 spec lists a couple of resrictions for how to convert
>>the TT font into a valid Type42 font. Maybe the Type42 generator of
>>xpdf (which is the basis for CUPS' pdftops filter) still has some
>>quirks.
> 
> 
> Franz reported that Ghostscript 8.x failed to process the PDF
> (and Ghostscript 7.x worked) but I don't understand how this
> is related to xpdf?
> 
> For me it looks like a problem in Ghostscript 8.x.
> In particular why does it abort because of a "Warning"?
> Or is the warning unrelated to the actual "Error"?
> Or does it perhaps skip the font definition because of the warning
> and then it fails later with an error because the font is missing?
> 
> 
> Kind Regards
> Johannes Meixner

The issue is related to xpdf according to the following:
- I converted the PDF in question to PostScript using the pdftops
   utility of the xpdf suite (version 3.01, the latest one),
   the language level of the output set to 2.
- gs 7.00 could render it without any complaints.
- both HP printers I tested with aborted with a firware error
   shown on the printer's display (one level2 printer, the other one
   a level 3 device).
- on a Xerox phaser 7400, which has a Adobe level 3 RIP (version 3015.xxx)
   the printout failed with a quite verbose error message, the essence of
   which was an invalidfont error, offending command 'stringwidth'.
   This backs the suspicion that the font in question (one of the chinese ones)
   is corrupt, presumably with respect to the character metrics.

But, as xpdf relies on the freetype library (freetype2) for handling TT fonts,
it may be an issue of either the freetype2 library or the TT to Type42 conversion
done by pdftops. But, as xpdf displays the PDF whithout complaints, I prefer the
latter hypothesis.

Helge


-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de