Skip to content

A Secret revealed: How to quick'n'dirty test for correct font embedding in print documents.

Tuesday, 16 January 2007  |  pipitas

I decided to leak a far well-guarded secret. It is about quick'n'dirty-testing of font embedding in print files. Pay attention: I use kpdf as the KDEPrint "preview" application. By default, your system most likely uses kghostview.

To change it:

  1. [alt]+[f2]
  2. type "kaddprinterwizard --kdeconfig",
  3. click "Run"
  4. click "Preview"
  5. enbable "kpdf"

"WTF?! WHAAAAAT??", I hear you screaming, "kpdf is for PDF, while the printing produces PostScript, and that can't be viewed by kpdf!".

[image:2633 align=left hspace=12 vspace=12 border=1 size=thumbnail][image:2634 align=right hspace=12 vspace=12 border=1 size=preview]

Yes and no. Yes, the printing application produces PostScript to sent off by kprinter to CUPS (or to the "Print to File ({PDF,PostScript})" dummy printers. And the same PostScript gets send by kprinter to the preview program (if previewing is enabled). When a recent kpdf version is fed with PostScript instead of PDF, it doesn't error out as in older versions. It silently runs "ps2pdf" (based on Ghostscript) to convert it to PDF and display this converted PDF.

Using kpdf for print previewing may have a few disadvantages:

  • ps2pdf will run first before a preview file is available
  • ps2pdf will take a bit of CPU and memory and temporary disk space

But kghostview possibly can consume _much_ more CPU and memory and temporary disk space when it chews on some nasty PS type input files directly -- files, which may go through ps2pdf well and fast...

But OTOH, you definitely have various advantages with kpdf over kghostview:

  • the preview window is easily resizeable
  • the preview window remembers its lastly used size
  • the preview image dynamically adapts to the size (if you use "Fit to Page")
  • the preview is searchable (if fonts are correctly embedded)
  • the preview app lets you go to "File --> Properties --> Fonts" and see the used font
  • the preview window title bar shows you the path to the temporary PostScript file
  • the preview will possibly be rendered much faster if you happen to print from a KDE $image application

Soooo, you can save the temporary preview PostScript file (it's created by your app, and should be the same that is sent to CUPS) for debugging should you need it. You can compare the fonts that are embedded (or not) to the ones you used when you created the document (or someone else created it).

Especially if you test PDF files for printing (and if you try to debug wtf this one PDF doesn't print properly), here's a hidden catch and benefit:

  • kpdf does use not Qt (like all other KDE apps) to produce the printfile
  • kpdf does instead use "pdftops" and the "Poppler" library, derived from Xpdf, to do this
  • so printing the PDF from kpdf will produce a Postscript file created by Poppler/Xpdf
  • telling kprinter to preview the file with kpdf (again) will prompt the (Ghostscript-based!) ps2pdf (re-)conversion

You'll now have 2 windows of kpdf open:

  1. the "original" PDF
  2. the previewed PDF, that has undergone a "(Poppler-)pdftops" --> "(Ghostscript-)ps2pdf" conversion

For both windows you can look at the fonts and other details. For both windows you can look look at the "File --> Properties --> Fonts" details, and compare if they are the same, if all originally embedded ones are still embeddded, or if a font was replaced by another one. In other words: it is a quick'n'dirty, but comfortable check if one important part of the software stack used in your printpath works as expected, or if you need to blame CUPS or the specific printer driver for any failure.

One example from today was this bug report. The reporter had this problem: "There is a barcode in the pdf file located at: [$other_testfile] This barcode displays correctly, but when the file is printed the barcode is printed as a solid black block."

What did I do to check this out for bug status CONFIRMED or INVALID? Open the file, look at the document info (yup, the barcode is embedded and has the name EanP36), print the file with "Preview" enabled in kprinter, look at the barcode at the bottom of the file (yepp, looks fine), check the document info (OK, the same barcode font still embedded, and the other fonts are also the same ones).

Actually, the font names will have funny prefixes like "WGVWHM+" before the real name. This is an indication that the font was not completely embedded into the file, but only as a "subset" of the full range of its glyphs.

In any case: bug #96394 is now closed. WORKSFORME + INVALID. (Of course, at the time of reporting it may have been perfectly valid bug report about one of the components of the conversion chain; the reporter must have had a buggy Ghostscript or kpdf or poppler library -- the report was more than 2 years old).

You try it now yourself, please. I would be interested if there are still installations out there that do not work for this particular file. Use the procedure I described. If it fails for you, tell me which versions of kpdf, Ghostscript, Poppler you've installed. At least one of these components must be outdated then. Oh, and you don't need to waste paper: you can cancel the printing after the preview. And you don't need a real printer either: Just use a "Print to File (XXX)" printer in kprinter's list.

I intend to find someone who makes this procedure script-able (Bash and DCOP/DBUS, and possibly Kross) in order to contribute to the implementation of my previous uhmm... proposal. Some nice, quick regression test script with a few standard (to be determined) input files, that creates a text report if everything turns out as we want it, eh? That can be run by anyone, to see if his own system also works as expected....

Now if only kpdf had a DCOP interface to query for embedded fonts, page sizes and other things....