Re: [Silgraphite-fonts] Should attachment+positioning void the advancewidth of glyphs or not?

[Martin H. <mar...@si...>]

Dear Shriramana,

> As per the Graphite behaviour seen via HB and XeTeX (I haven't trained
> myself to use gr2fonttest directly much yet) I understand that when a glyph
> has an advancewidth, but it is attached+positioned w.r.t another glyph,
> then the advancewidth is voided and unless any composite metrics are set in
> terms of kerning etc, the advancewidth of the base is the only remaining
> one.

No this is not what graphite does. Herewith my best take on the behaviour:

When a diacritic is added to a base, the distance the origin of the diacritic is to the left of the base origin is calculated. The base position (and therefore the diacritic position with it) is advanced by this amount. The effect now is that the combined cluster is shifted (along with its advance) such that the left most component (diacritic or base) of the cluster is at the cluster start (the origin of the base if there were no diacritics).

And if that isn't confusing enough, for the purposes of right to left rendering, this cluster shifting only happens if the advance of the diacritic is non-zero.

In addition, if the diacritic has a non-zero advance, the same trick is applied to the advance for the cluster. If the positioned advance (origin + advance) of the diacritic is to the right of the advance of the base, the cluster advance is increased to this amount.

So, the 'some space' is clearly defined and under your control.

> For instance, in Kannada, when one has a consonant cluster of many
> consonants, the sub-base consonants start moving to the right to avoid
> extreme vertical advance. So the font maker may have a reason for providing
> a conjoining form a non-zero advance width. Cancelling it automatically and
> having to reset it to its original value (which is however not recoverable
> in GDL programmatically AFAICS) is inappropriate IMHO. If the font maker
> wants a glyph to have a zero default advancewidth, then s/he should set
> that advancewidth to zero. It can always be made non-zero in the GDL.

In addition. If you were right attaching some diacritic to a base and you wanted to treat that right attached diacritic as if it were a base and allow the cursor to appear between them (at the advance of the base) then you would set insert=1 on the diacritic when you attached it. Not sure if that is what you are wanting to do.

> As such, even though a glyph will always be combined as per the GDL, Gr
> should not cancel its advancewidth. This will help enforce consistent font
> metric setting on part of the font maker.
> 
> Thoughts?

It really does do what you want it to do :)

> 
> As for the conversation below, it is not clear to me why Gr2 adds "some
> guard space". The point of Gr is providing full control (and
> responsibility) of all positioning/spacing issues to the font maker. IMHO
> Gr should not make any assumptions on behalf of the user as to what space
> should be added where.
> 
> Also, what was the outcome of the conversation between Martin and Sharon
> mentioned below?

> > No. For Graphite1, if the advance-width is non-zero, it will affect
> > the advance of the base character. If the advance width is zero, the
> > metrics of the diacritic will be ignored as far as positioning the
> > base. (It should be possible to set the advanced width to zero using
> > GDL, even if the font uses something different.)

Yup. Graphite 2 does that now too, but only for rtl. The reason we don't disable left guard space protection for ltr is that you can achieve what you want by positioning your glyph in relation to its origin. For rtl that can sneak up and bite you so we allow for turning off the guard space protection.

I bet you wish you hadn't asked now ;)

Yours,
Martin