desktop-packages team mailing list archive

[Sergio Gelato <Sergio.Gelato@xxxxxxxxxxx>]

Public bug reported:

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.

** Affects: cairo (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cairo in Ubuntu.
https://bugs.launchpad.net/bugs/1411581

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

Status in cairo package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1411581/+subscriptions