Bug 194498 - [FreeType] Unable to render some Hebrew characters
Summary: [FreeType] Unable to render some Hebrew characters
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 184448 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-02-11 05:13 PST by Alberto Garcia
Modified: 2019-04-02 04:46 PDT (History)
7 users (show)

See Also:


Attachments
Test case (660 bytes, text/html)
2019-02-11 05:14 PST, Alberto Garcia
no flags Details
Test case (NFC normalization) (664 bytes, text/html)
2019-02-11 05:21 PST, Alberto Garcia
no flags Details
Patch (2.33 KB, patch)
2019-02-12 04:48 PST, Carlos Garcia Campos
mcatanzaro: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alberto Garcia 2019-02-11 05:13:25 PST
WebKitGTK is unable to render some Hebrew characters, displaying square boxes instead.

Here's the link to the test case:

   http://bibleconsultants.nl/downloads/webkit2gtk/resources.html

Here's what it's supposed to look like:

   http://bibleconsultants.nl/downloads/webkit2gtk/right-rendering.png

And here's how it appears on WebKitGTK:

   http://bibleconsultants.nl/downloads/webkit2gtk/wrong-rendering.png

The problem seems to be that some of those characters are decomposed (i.e combinations of two or more characters). The W3C validator does indeed emit a warning saying that "Text run is not in Unicode Normalization Form C", but that doesn't seem to be a requirement for HTML and it should be possible to display the text correctly.

I reproduced this problem with WebKitGTK 2.22.6, and master seems to be affected as well.

Other tests (using Debian stretch packages):

  - Chromium 71.0.3578.80 also fails.
  - Firefox-ESR 60.5.0 works fine.
  - Chrome 71.0.3578.98 works fine.

Other apps (Gedit, gnome-terminal, ...) seem to work fine as well.
Comment 1 Alberto Garcia 2019-02-11 05:14:39 PST
Created attachment 361673 [details]
Test case

Here's a simpler version of the text case.
Comment 2 Alberto Garcia 2019-02-11 05:21:18 PST
Created attachment 361674 [details]
Test case (NFC normalization)

Here's the same file as before but normalized using Unicode NFC.

This one can be displayed correctly.
Comment 3 Michael Catanzaro 2019-02-11 07:14:41 PST
Note this affects many languages, not just Hebrew.
Comment 4 Alberto Garcia 2019-02-11 07:15:48 PST
(In reply to Michael Catanzaro from comment #3)
> Note this affects many languages, not just Hebrew.

Yes, most certainly, but this is the test case we have.
Comment 5 Carlos Garcia Campos 2019-02-12 04:48:01 PST
Created attachment 361789 [details]
Patch
Comment 6 Alberto Garcia 2019-02-12 07:37:51 PST
(In reply to Carlos Garcia Campos from comment #5)
> Created attachment 361789 [details]
> Patch

I tried it in the 2.22.x branch, I confirm that it fixes this issue.
Comment 7 Michael Catanzaro 2019-02-12 10:36:01 PST
Comment on attachment 361789 [details]
Patch

D'oh!

It's frustrating that so many ICU APIs have to be called twice in a row to be used safely, instead of just allocating the buffer for us. Oh well.
Comment 8 Carlos Garcia Campos 2019-02-13 01:10:20 PST
Committed r241402: <https://trac.webkit.org/changeset/241402>
Comment 9 Carlos Garcia Campos 2019-04-02 04:46:41 PDT
*** Bug 184448 has been marked as a duplicate of this bug. ***