[HarfBuzz] behavior of mark-width-zeroing

[Jonathan Kew]

On 9/6/14 22:15, Behdad Esfahbod wrote:
> On 14-06-09 10:12 AM, Jonathan Kew wrote:
>> Hi Behdad,
>>
>> Our current mark-zeroing code, in zero_mark_widths_by_gdef() and
>> zero_mark_widths_by_unicode(), modifies only the advance of the glyphs, so
>> that they no longer take up any space on the line.
>
> Right.
>
>
>> I'm wondering whether we should also adjust the offset, by subtracting the
>> advance from it before we zero the advance. (Though perhaps only if there's no
>> GPOS positioning?)
>
> We definitely need to test what Uniscribe does, eg. for Latin.  Note that any
> offsetting should only happen in LTR, not RTL.
>

Good point - doing it in RTL has the opposite effect, and makes things 
worse. (Indeed, that showed up as a test failure when I ran an 
experimental patch.)

>
>> In particular, this is required for correct rendering of old fonts such as MS
>> Sans Serif codepage 874 (Thai), which has spacing glyphs for the Thai
>> vowel/tone marks.
>
> Note that Thai and Hangul might be more affected as they have
> fallback_position turned off.  The default shaper has fallback_position turned
> on which takes care of this.

Ah, right - with fallback_position it shouldn't be an issue. So this 
really is primarily about Thai.

>
>
>> AFAICT, what Uniscribe does with it is to zero their advance
>> width *and* offset them to the left by their original advance, so that they
>> overstrike the preceding glyph, even though the images in the font appear to
>> the right of the origin.
>>
>> WDYT? Can you think of fonts where this would *not* be appropriate?
>
> The reason we turned fallback positioning off for Thai had to do with vertical
> positioning IIRC.  Maybe we should turn it on for horizontal but not vertical?

I don't think so. The Thai glyphs are designed to be placed relative to 
the right-hand edge of the base, not centered. (And the results I'm 
getting with this exactly match what Uniscribe does.)

>   I don't remember why we did that for Hangul, perhaps because of the special
> logic we have for tone marks.

Sounds right. Hangul doesn't have a whole lot of marks to worry about, 
but the ones it does have are pretty special, and fallback positioning 
wouldn't do the right thing with them.


Suggested patch in https://bugzilla.mozilla.org/show_bug.cgi?id=985220 
(for the version of harfbuzz we currently have in our tree, though I 
don't think this code has changed substantially?). This fixes the Thai 
version of MS Sans Serif, and shouldn't disrupt anything else AFAICS. 
Please take a look and see if it seems reasonable to you - thanks.

JK