Possible bug generating certain Unicode

[dVVIIb]

Dompdf 0.8.3, 1.0.2
PHP 8.0.12
Windows 10 Pro 21H1

Unicode glyphs that need to be combined seem to be rendered separately. For example, see if you can get the following Sinhala greeting rendered properly using above mentioned versions.

ආයුබෝවන්!

I find that බෝ is rendered as බ ෝ, without the gap, but separately.

When you advertise that Dompdf supports Unicode, a user might unwittingly integrate it into their applications/products assuming it works as advertised, but will have to spend more time and effort later switching to a different solution when they find that it does not, as was our experience.

Our current attempts are to switch to wkhtmltopdf + phpwkhtmltopdf, which seems to work properly, except possibly for proper handling of html footer tag, etc., but involves changing a lot of existing legacy code, including CSS.

Also, our production environment is likely to be CentOS 7/8, PHP 7/8.

I have been asked to look into the Dompdf code to identify and fix the issue if I have the time, and I may get around to that later, but in the meantime, if someone familiar with the code can maybe take a look, all good.

[bsweeney]

There have been similar reports in the past related to, for example, Arabic. It's true that Dompdf does not yet support type shaping. Watch #2107 for updates on support for that functionality.

[bsweeney]

Going to close this ticket in favor of 2619 as the tracking ticket for the necessary functionality but will review comments here as we build out better support for Sinhala.