Comment 22 for bug 227186

xpdf/poppler (via Gentoo’s ebuild) can print wrong.pdf to PS in an
optimal way (the fonts are converted to PS Type3 fonts and the strings
are shown).

Ghostscript 8.63’s cairo backend handles wrong.pdf as well as expected:
all of the glyphs are output as filled paths. (The cairo backend is
advertized to do just that with any fonts). The filled paths, though,
look like squares making up the individual pixels of the bitmaps.

GS 8.63’s pdfwrite does a much better job than you got from 8.61:

  :; pdfinfo wrong.printed.pdf
  Producer: GPL Ghostscript 8.61
  CreationDate: Tue Sep 9 12:03:47 2008
  ModDate: Tue Sep 9 12:03:47 2008
  Tagged: no
  Pages: 1
  Encrypted: no
  Page size: 595 x 842 pts (A4)
  File size: 299281 bytes
  Optimized: no
  PDF version: 1.4

  :; pdfinfo wrong_pdfwrite.pdf
  Producer: GPL Ghostscript 8.63
  CreationDate: Fri Sep 12 13:54:23 2008
  ModDate: Fri Sep 12 13:54:23 2008
  Tagged: no
  Pages: 1
  Encrypted: no
  Page size: 595.28 x 841.89 pts (A4)
  File size: 7804 bytes
  Optimized: no
  PDF version: 1.4

Said output also looks better when viewed on screen.

Also, poppler’s pdftops seems to work well on wrong.pdf (as of poppler
commit 217c0d1f80a78713977a7bfbe680fce90f1c6b36). As well as xpdf/poppler
does.

This suggests that if the bug is in poppler it has been fixed, or that
the bug in in evince.

Unfortunately, I cannot test in evince because I seem to have updated
poppler and evince but not poppler-bindings, which prevented evince’s
configure from finding libpoppler. [SIGH]

I’ll have to update again and try then. Probably not until Sunday,
though.