Some characters becomes ?? in pdf templates after upgrade

[novastream]

Hi,

After upgrading to 9.0.0 (via cli) all special chars in my PDF-templates are displayed as ??.

They are displayed correctly when editing the template.

Some chars that are not displayed correctly:
å ä ö á

Any ideas whats wrong?

[ChrisSka83]

I noticed the same thing today, in my case it's the letter “ß”.
But after checking, the other German characters don't work either.

[novastream]

I noticed the same thing today, in my case it's the letter “ß”.
But after checking, the other German characters don't work either.

Hi Chris,

Think I found what causing the issue, if I remove my logo or any images from the PDF-template the special chars starts working again. Going to test if I need to resave the image or save the image in another format.

[novastream]

So the issue seems to be introduced in domPDF 3.0.0 and is still there in 3.01, 3.0.2 and 3.1.0. You can downgrade to domPdf 2.0.8 by defining version in your composer.json file or if you are not using composer you can just download the domPDF 2.0.8 src package and replace it in your vendor directory.

If doing it manually you should be aware of that you need to replace vendor\dompdf\dompdf and not vendor\dompdf

[ChrisSka83]

I have now simply replaced the current version with version 2.0.8.
And... now I have my special characters again.
Thank you novastream

[yuri]

It works fine for me. With an image in a template.

Maybe using custom fonts?

[ChrisSka83]

I didn't even have a picture in the template.
I also use this function to print labels and there was only a QR code and text on it.
Umlauts were always displayed as “??”.
Texts with ä,ö,ü,ß -> ??

But with the old version 2.0.8 I don't have these problems.

[novastream]

It works fine for me. With an image in a template.

Maybe using custom fonts?

I'm using Dejavu Sans and tested a couple of the default fonts without any success. Only time I got it to work where when I removed my company logo. I also installed a fresh version of EspoCRM on my desktop computer and could reproduce the error when created a simple layout with ÅÄÖ and a image.

Tested all the dompdf versions mentioned above and with 2.0.8 the issue dissapeared.

[novastream]

I'm using Dejavu Sans and tested a couple of the default fonts without any success. Only time I got it to work where when I removed my company logo. I also installed a fresh version of EspoCRM on my desktop computer and could reproduce the error when created a simple layout with ÅÄÖ and a image.

Tested all the dompdf versions mentioned above and with 2.0.8 the issue dissapeared.

I've also attached a minimal example:


And this is the result:

[novastream]

So back to version 3.0.0 I found this in the dompdf documentation:

https://github.com/dompdf/dompdf/wiki/UnicodeHowTo

and by adding:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

to application\Espo\Tools\Pdf\DomPdf\HtmlComposer.php (below {$titleHtml} in the composeHead function seems to solve the issue for me.

[yuri]

Still could not reproduce.

[yuri]

Could you show the raw HTML (code view) of your minimum example?

[novastream]

Could you show the raw HTML (code view) of your minimum example?

Sorry, here it is:

[yuri]

I'm really perplexed why I cannot reproduce. Nevertheless I added the metatag now. Hope it won't break anything.

[novastream]

I'm really perplexed why I cannot reproduce. Nevertheless I added the metatag now. Hope it won't break anything.

Yeah, feels like maybe it has something to do with our localization or maybe database table collation? Nevertheless I don't understand why it only triggers when adding a image . Thank you for your time and help.