Comment 7 for bug 656207

Revision history for this message
madbiologist (me-again) wrote :

The problem seems to be that the 3 serifed Minion fonts are being replaced by a non-serifed font:

sturner@home01:~$ fc-match HelveticaNeue-Black
DejaVuSans.ttf: "DejaVu Sans" "Book"
sturner@home01:~$ fc-match Symbol
Symbol.pfb: "Symbol" "Regular"
sturner@home01:~$ fc-match HelveticaNeue-Light
DejaVuSans.ttf: "DejaVu Sans" "Book"
sturner@home01:~$ fc-match Minion-Regular
DejaVuSans.ttf: "DejaVu Sans" "Book"
sturner@home01:~$ fc-match Minion-Semibold
DejaVuSans.ttf: "DejaVu Sans" "Book"
sturner@home01:~$ fc-match Minion-Bold
DejaVuSans.ttf: "DejaVu Sans" "Book"

A Wikipedia page about the Minion font is located at http://en.wikipedia.org/wiki/Minion_%28typeface%29

This font was not embedded in the PDF so another font must be substituted. This is a regular pitfall of not embedding fonts which are not one of the standard PDF fonts, and also occurs on Windows. If Adobe Reader can display this font correctly on Linux presumably that is because this font was designed by Adobe.

I am wondering whether we should close this bug on the basis that the font should have been embedded in the PDF file. On the other hand we could re-target this bug to the fontconfig package on the basis that it should choose a serifed font to replace Minion rather than a non-serifed font.