916102 - Combining characters positioning a little off when styled separately

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect)

Description

[Shai Berger]

Attachment: The letters and the off-positioned diacritics

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 Iceweasel/23.0.1 (Beta/Release)
Build ID: 20130821135347

Steps to reproduce:

Trying to render a composite character with separate styling for the composing part appears slightly broken on Linux (and completely broken on Windows).

I am speaking of something along the lines of

<span class="some-class"><span>&#x05d1;</span>&#x05b8;</span>

05d1  is HEBREW LETTER BET (ב)‎; 05b8 is HEBREW POINT QAMATZ, a combining character showing under the letter (with BET: בָ). This comes from a web application for keyboard layouts, wishing to display a Qamatz -- by composing it with a "carrier" letter, but styling the letter as "faded" and emphasizing the point.



Actual results:

Firefox (Debian Iceweasel) on Linux displays the point a little shifted to the left (Hebrew is RTL, this is "forward").

In http://webkeys.platonix.co.il/layouts/show/system/si1452/ you can see the effects on the "key" of the letter E. You can see real damage on the "keys" immediately to the left, Q and W, where the composing dots on the letter SHIN (ש) should have appeared on opposite sides, (שׁ, שׂ) but both appear on the left.



Expected results:

The characters should have displayed with the same positioning as in the text of this bug, just different styling.

Of note: The validity of starting a text run with a combining character, exactly for this purpose, was discussed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=13502 and found to hold.

Comment 1

[Shai Berger]

Possibly related:

#387653 -  Combining characters positioned wrongly in RTL text

#729993 -  Combining marks cannot be colored independent of their base glyphs with OpenType fonts
(although the problem I'm seeing is sort-of the opposite of the problem described there).

W3c bugs:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12400
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13502 (already mentioned above)

Comment 2

[Jonathan Kew [:jfkthame]]

The positioning problem in the keyboard-layout example arises because the diacritic is being styled with a different font from the base character (it's bold, whereas the base letter is regular). Proper diacritic positioning is dependent on glyph metrics and OpenType layout tables within a given font, and is liable to break across font-run boundaries as the "association" between the two glyphs is broken by the font change. So you'll just get whatever default positioning the diacritic has, depending how it has been drawn in the font.

In the case of the TaameyAshkenaz font being used there, the SHIN DOT and SIN DOT diacritics are drawn identically, as zero-width glyphs with the dot centered over the glyph origin. And so they display identically, in the absence of any attachment rule to position them on a base letter. I'd consider that a weakness in the font, in that it *requires* OpenType positioning rules to be applied in order to make any distinction between these two characters. IMO, it would be better to design the glyphs such that *even in environments with "dumb", OpenType-free rendering* there is still a visible distinction between diacritics that are supposed to be placed differently, even though their positioning may be less than ideal on some base letters.

Disabling the TaameyAshkenaz font and using Ezra SIL instead, for example, provides a clear distinction between the SHIN and SIN dots, as Ezra SIL has been designed with the dots offset from the glyph origin so that *by default* (in the absence of specific positioning/attachment), they will "overstrike" the preceding character, but by different amounts. As a result, Ezra SIL works better in general for this layout; nevertheless, positioning of the diacritics is still far from perfect as they're just being rendered at "default overstriking" positions rather than using glyph-specific attachment points.

As a further experiment, you can either remove the "bold" styling from the diacritics, or add it to the base letters. (The Web Developer / Inspector tool makes it fairly easy to experiment with tweaks like this on the live site.) As soon as you do this, the base letter and diacritic will be in the same font; then the OpenType rules within that font come into effect, and the diacritic positioning is correct.

Unfortunately, this has another side-effect: once the letter and diacritic are being rendered with the same font, they become part of a single "cluster" for rendering purposes, and the diacritic loses its separate coloring - i.e., you run into bug 729993.