Open Bug 1269484 Opened 9 years ago Updated 2 years ago

Incorrect rendering of Unicode COMBINING BREVE in Verdana font

Categories

(Core :: Graphics: Text, defect, P3)

46 Branch
x86_64
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: ruvim.pinka, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: testcase, Whiteboard: [gfx-noted])

Attachments

(2 files, 2 obsolete files)

Attached image actual (in Firefox) and expected (in Chrome) results (obsolete) (deleted) —
In some fonts the symbol U+000306 COMBINING BREVE is rendered incorrectly — it is shifted to the right. For example, in Verdana font (see screenshot). Another question is why the breve form depends on the second mentioned font — compare the first and the second case. One-line testcase: {actual}_{expected} data:text/html,&%231080;&%23774;_&%231081;<style>body{font-family:Verdana;}</style> The similar Bug #925684 is not reproducible for me.
Attached file testcase html (obsolete) (deleted) —
Component: General → Graphics: Text
Keywords: testcase
Product: Firefox → Core
This happens because Verdana does not actually support U+0306. So this character gets mapped to the next font in the font-family list (or a fallback of some kind, if no suitable font is listed), and in general diacritic positioning won't work well if the base character and the combining mark are taken from different fonts (and therefore shaped as separate text runs). Chrome gives a better result here because it applies Unicode NFC normalization during its rendering, and so the sequence <U+0438, U+0306> is mapped to the single precomposed character U+0439, which IS supported in Verdana. Currently, Firefox doesn't do this; it chooses fonts based on their character coverage for the text as originally provided. Applying NFC when rendering is often helpful (e.g. for cases like this), but unfortunately there are also some cases where fonts handle it worse than the decomposed form, so whether to do this is not as simple a decision as it might seem from a single example. See also bug 543200, which would help here.
Depends on: 543200
Whiteboard: [gfx-noted]
Attached file testcase html (deleted) —
Change this testecase, add "m̆ " variant to be sure that NFC normalization doesn't matter — there is no such glyph in Verdana (see https://www.myfonts.com/fonts/ascender/verdana/regular/glyphs.html — though don't sure that the set is the same for the font from Microsoft) Also add Courier New font with the same issue. It is strange that it's fine for "и" and wrong for "m".
Attachment #8747937 - Attachment is obsolete: true
Update screenshot (add 'm' letter, "Courier New" and "PFRegal" fonts)
Attachment #8747936 - Attachment is obsolete: true
I have just noted that some versions of Verdana had bug regarding position for combining diacritical marks, see https://en.wikipedia.org/wiki/Verdana#Combining_characters_bug On my system (and in my tests) Verdana has version 5.05, Courier New — 5.11.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: