HP CP4525 printer confused by evince (libcairo 1.13.0~20140204-0ubuntu1) font naming mismatch

[Sergio Gelato]

I have an HP Color LaserJet Enterprise CP4525 with firmware 07.164.1, which supports PDF files natively (@PJL LANGUAGE=PDF), and a print server running Debian 7 (cups-filters 1.0.18 and its pdftopdf, and a PDF-enabled PPD).

I have been given a PDF file (from pdflatex) that uses four Type 1 font subsets (of four different simple fonts). This file gets printed correctly with /usr/bin/lp . Not so when using evince on Ubuntu trusty: then the printer substitutes a different font (but keeping the glyph widths from the font object in the PDF file, so the letter spacings look all wrong).

I've inspected the PDF file evince sends to the printer (which is not identical to the original PDF file: evince rewrites it) and noticed that the value of /FontName in the font program object doesn't match that of /FontName in the font descriptor object; the latter does match /BaseFont in the font object and has the form prescribed in §9.6.4 of the PDF 1.7 specification for font subsets. The /FontName in the font program object, on the other hand, is of the form /CairoFont-N-M, where N and M are integers.

If I hand-edit the PDF output by evince, replacing /CairoFont-N-M with the value of /FontName in the corresponding font descriptor object (and adjusting /Length and /Length1 as needed), the result gets printed with the correct fonts.

§9.6.2.1 of the PDF 1.7 specification (PDF 32000-1:2008, retrieved from Adobe's web site) does say that "[f]or Type 1 fonts, [BaseFont] is always the value of the FontName entry in the font program". One wonders, then, why Cairo changes the name. I could understand it if it wanted to make the font descriptors for two different subsets of the same font share the same font program object; but it doesn't take advantage of this. The sample file I have contains ligatures and accented letters, originally represented in a single font subset by using a non-standard encoding, and evince splits these font subsets into two parts, one of which uses /WinAnsiEncoding; each of the subsets gets its own font program object (with a different value of M in /CairoFont-N-M). So this is not the explanation.

I think it would be prudent, in light of HP's PDF interpreter's behaviour, for Cairo to adhere more strictly to the wording of §9.6.2.1 and use the same /FontName in the font program object as in the font descriptor object.

I think I'd also like for pdftopdf to incorporate a workaround for this, simply because I have more control over the print server than over the clients. But that's for another (wishlist) bug report.

[madbiologist (me-again)]

Can you please attach a PDF that we can use to reproduce this problem?

[Launchpad Janitor (janitor)]

[Expired for cairo (Ubuntu) because there has been no activity for 60 days.]