Can you please attach a PDF that we can use to reproduce this problem?
** Tags added: trusty
** Changed in: cairo (Ubuntu)
Status: New => Incomplete
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cairo in Ubuntu.
HP CP4525 printer confused by evince (libcairo
1.13.0~20140204-0ubuntu1) font naming mismatch
Status in cairo package in Ubuntu:
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
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.
§188.8.131.52 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
§184.108.40.206 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.
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~desktop-packages
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp