font substitution fails if font name contains a dash

Bug #1275136 reported by Joachim Schwender on 2014-01-31
This bug affects 1 person
Affects Status Importance Assigned to Milestone
fontconfig (Ubuntu)

Bug Description

I have PDF that contain a font named Code-128, not embedded. Just installing this font does not help: it is not picked properly and evince uses DejaVu for rendering, which is bad for a barcode.
A fc-list does show the installed font. A fc-match does not work and always returns "DejaVu Sans" "Book"

Expected: fontconfig picks the installed font and uses it for rendering in evince. fc-match returns the font name it it matches, no matter what character is contained in the name.

Tested on 12.04 and 13.10 (x86_64)

Temprary workaround i currently use:
I used fontforge to change the font by removing the dash in the font name. Then i implemented a substitution for Code-128 to be substituted by Code128.

Result: evince displayed the font properly but fc-match still does not work.

Unfortunately i have no influence on the PDF generation, they are generated by a German Ministry of Interior and i have been struggling for three years now to get them to create only PDF-A (fonts embedded), but they refuse to implement that without giving meaningful arguments. We, like many other companies are forced to utilize these buggy PDFs, probably most companies use Windows+AdobeReader and don't have that problem...

Joachim Schwender (jschwender) wrote :

For legal reason i cannot drop the original files, therefore i upload similar examples, where the font name alsoo contains a dash.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers