dompdf not displaying some of latin characters

Question

I am using latest stable 0.6 dompdf version but I am unable to display some latin characters, I see that documentation is for now incomeplete.

So far I am trying to use Open Sans font, I have even converted it to afm format, but still some display are displayed with ? instead of our latin characters 'č, ć, đ, ž'.

Font is downloaded as ttf, and font definition is added to dompdf_font_family_cache.dist.php file as follows:

'open sans' => 
  array (
    'normal' => $rootDir . '/lib/fonts/OpenSans',
  ),

Outputing html contents to browser renders these characters fine. Is there any official solution, because load_font.php is missing or should update to 0.7-beta and use @font-face instead?

What documentation do you need? There's information on font/character set support as well as information on how to expand the supported character set by enabling Unicode support. There are also a number of questions on StackOverflow related to this particular topic. — BrianS
Ultimately decided there was some room for additional information on this topic. — BrianS

BrianS BrianS · Accepted Answer · 2016-01-28T03:38:06

Character Encoding

The default encoding of a PDF document is Windows ANSI ⁽¹⁾. This encoding provides limited character set support that does not include the characters specified in the question (č, ć, đ, ž). So while the text is technically latin-encoded the specific encoding that supports those characters (ISO-8859-5) is not the same as the default one provided provided in PDF documents (Windows-1252, aka Windows ANSI, which is pretty much ISO-8859-1).

Font Metrics

With the character encoding issue in mind you took the right approach to add support for your characters by loading a font. The means by which you've done it, however, will not get you the expected results. dompdf (when using the CPDF backend) utilizes font metrics to determine how to lay out the text of a document. The font metrics come in two forms, AFM (Adobe Font Metrics) and UFM (Unicode Font Metrics). These two forms correspond to the two possible encodings supported by dompdf, Windows ANSI and Unicode. The fact that your font metrics are in AFM format indicates to dompdf that the font is encoded as Windows ANSI.

Loading Fonts

While you can modify the dompdf_font_family_cache.dist.php file it is not recommended. Since that file is included as part of the distribution any updates you perform could over-write the file. When using any of the supported font-loading methods dompdf will create a file called dompdf_font_family_cache.php to store name/location information for your custom fonts. If you want to tweak your custom font information you would do so in this file. This file is typically stored alongside the TTF and AFM files associated with the custom fonts (not necessarily in the dompdf/lib/fonts directory ... depending on your configuration).

I would recommend against manually editing dompdf_font_family_cache.php. Rather I would use the CSS @font-face rules to define and load fonts if for no other reason ease of use. If you're inclined to use a command line tool to pre-load your fonts the load_font.php script is still included in the 0.6.x releases of dompdf (not sure why you think otherwise). If you want to move to 0.7.0 you can find an updated version of the load_font.php script in the dompdf-utils project.

Lastly, if you continue to have trouble you can always try using one of the bundled DejaVu fonts (available starting with dompdf 0.6.0).

(1) OK, yes, there are a few possible encodings. But for the most part you can consider Windows ANSI the default.

dompdf not displaying some of latin characters

1 Answers