0

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?

Alan Kis
  • 1,790
  • 4
  • 24
  • 47
  • What documentation do you need? There's information on [font/character set support](https://github.com/dompdf/dompdf/wiki/About-Fonts-and-Character-Encoding) as well as information on how to expand the supported character set by [enabling Unicode support](https://github.com/dompdf/dompdf/wiki/UnicodeHowTo). There are also a number of questions on StackOverflow related to [this](http://stackoverflow.com/search?q=dompdf+cyrillic) [particular](http://stackoverflow.com/search?q=dompdf+character) [topic](http://stackoverflow.com/search?q=dompdf+font). – BrianS Jan 28 '16 at 01:23
  • Ultimately decided there was some room for additional information on this topic. – BrianS Jan 28 '16 at 03:39

1 Answers1

1

Character Encoding

The default encoding of a PDF document is Windows ANSI (1). 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.

Community
  • 1
  • 1
BrianS
  • 13,284
  • 15
  • 62
  • 125
  • awesome answer. I prefer dompdf over other pdf render libraries, and looking forward to updated version. I am not doing mass pdf creation, but what is better from point of performance, loading font with '@font-face' or manually loading via command line? Also, I have tried to load font with '@font-face', as I see font changed, but I have still issue with character encoding. – Alan Kis Jan 28 '16 at 07:59
  • As far as I see, I am failing at this point "Configure DOMPDF for Unicode support", but as config.inc.php is not included nor supported, and going through Options class, I am unable to set or enable Unicode support at runtime. – Alan Kis Jan 28 '16 at 08:31
  • @AlanKis you might see slightly better performance if pre-loading the font. When using `@font-face` dompdf has to determine if the font has already been loaded (though it won't process the metrics a second time if it has). As far as Unicode support, always enabled starting with 0.7.0. – BrianS Jan 29 '16 at 14:33