[HarfBuzz] Positive mark AW [was on fallback shaping...]

[Martin Hosken]

Dear Behdad,

> 
>   - Positive mark advance width:  This is kinda similar to the Arabic case,
> except that because of the rendering direction (rtl), for Arabic it's enough
> to set the mark advance width to zero, but in Latin, we need to also make sure
> that the mark resides on the left side of the origin, not the right side,
> after we zero the advance.
> 
> Or we can take a completely different approach: use 'canned' tables to do a
> full 'mark' and 'mkmk' fallback implementation:
> 
> In this solution, we first populate GDEF's mark attachment type by the Unicode
> combining class of the characters, then use a pre-generated GPOS table to
> attach marks to bases based on their combining class type, and glyph extents.
>  To do the attachment we use a special get_contour_point callback that would
> use the original font's get_glyph_extents to return one of the few
> predetermined attachment points for the glyph (think "top-right", "bottom", etc).
> 
> Using the same technique we can also do 'mkmk' positioning.  We can even do
> this if the font has a GPOS table but not 'mkmk' (and no mark attachment
> classes for that matter).
> 
> One problem still remains though: mark advance widths are still not set to
> zero using the above stuff.  Previously we used to zero the mark advance width
> in MarkBase and similar lookups, but stopped doing that since it broke some
> well-designed fonts (DejaVu Sans Mono for example).  I'm not sure how to zero
> the advance width short of adding fallback code to do that, but then I'm not
> sure which mark classes should get that treatment.

FWIW what happens in graphite is that each mark is positioned relative to its base and the space allocation box (origin to advance width) for the base is updated to be the maximum of the space allocation boxes of the base and the marks (i.e. take the minimum origin and the maximum advance width locations for each positioned mark). Then the base is shifted to ensure its space allocation box starts at zero and the advance for the base is the updated advance for the space allocation box.

This takes into account space on marks but only if it causes any real affect.

The danger with this approach is that it is very different from other shaping engines which ignore mark advance on markbase and markmark attachment, much to my frustration when trying to implement stuff. A work around has been to use cursive attachment, but I notice that you don't allow cursive attachment if a glyph is a mark.

HTH,
Yours,
Martin