DOMpdf failing to render certain accented characters

I’ve noticed some issues with DOMpdf when trying to generate PDFs using
their internal Helvetica font. After banging my head against a wall for
a few hours trying to “fix” UTF-8 support, it turned out UTF-8 support
was working fine. Essentially DOMpdf’s internal Helvetica font didn’t
support a few polish characters. Specifically the Sacute, sacute and a
few others like this. This was a bit of a killer problem for my
requirements so I needed a work-around. My workaround was to use Arial
fonts(they were close enough), but if you really need Helvetica you
could source a copy of the .ttfs and replicate these steps.

Download Arial fonts

wget -O arialit.ttf
wget -O arialbit.ttf

This downloads arial, arial-bold, arial-oblique and arial-boldoblique.

Generate compatible dompdf files

Pull up a terminal and cd into your dompdf folder. If you’re using
composer, it’ll be /vendor/dompdf/dompdf

php load_font.php arial ~/arial.ttf ~/arialbd.ttf ~/arialit.ttf ~/arialbit.ttf

You should now see an entry in lib/fonts/dompdf_font_family_cache.php

arial’ =>
array (
‘normal’ => DOMPDF_FONT_DIR . ‘arial’,
‘bold’ => DOMPDF_FONT_DIR . ‘arialbd’,
‘italic’ => DOMPDF_FONT_DIR . ‘arialit’,
‘bold_italic’ => DOMPDF_FONT_DIR . ‘arialbit’,

You can now reference the Arial font-family in your DOMpdf stylesheets
and have it render some nice Helvetica like fonts.

If you are using composer with DOMpdf, I would highly recommend not
leaving your custom fonts in DOMpdfs vendor folder. Copy the fonts
directory somewhere in your projects directory, and over-ride this
variable with your own def, referencing the new folder location.

def(“DOMPDF_FONT_DIR”, DOMPDF_DIR . “/lib/fonts/”);

This means you shouldn’t need to rely on dodgy customisations to the
vendor folder.