Re: [Silgraphite-fonts] Problems with attaching a reordered vowel sign to its base

[Shriramana S. <sa...@gm...>]

On Sat, Jul 28, 2012 at 12:36 AM, Sharon Correll <sha...@si...> wrote:
> In the original Graphite engine, side-by-side attachments are supposed
> to preserve the order of the glyphs. So I expect/hope what you're
> seeing is in Graphite2.

Yes as I said it is the behaviour seen in LibO. In XeTeX (see
https://sites.google.com/site/jamadagni/files/temp/krishna-tamil-reordered-attachment-test-1.zip),
attaching ை to க does not cause the reordering. This all the more
strengthens my contention that Gr2 should not change the positioning
of glyphs when in-place attachment is requested. (Is
http://hg.palaso.org/graphitedev/rev/ad1e222b3b16 supposed to address
my complaint since its comment reads "Fix ordered attachment
defaults"?)

BTW do I correctly understand that if a (diacritic) glyph is attached
to another using attach.at and .with, and the advancewidth of the
attached (diacritic) glyph is in fact non-zero in the font, then after
attachment such advancewidth is ignored?

In my Krishna Tamil font's current devel version (available at
https://bugs.freedesktop.org/attachment.cgi?id=64767) I attach
chandrabindu-s to base characters, and the chandrabindu glyph in the
font actually has an advancewidth of 526 but after attachment I don't
see any corresponding shifting of the next glyph. This behaviour
*seems* correct and appropriate, as it allows me to set a non-zero
advancewidth to "automatically" make my diacritic a spacing character
if a suitable base for attachment is not found (so that it will not
overlap with any succeeding duplicate glyphs).

So this behaviour is appropriate, then it seems that (see in the
Google Sites zip file linked above) XeTeX has not at all processed the
second level diacritic, since it is shown with a positive
advancewidth. But if you people are not maintaining Gr1 anymore, I had
better just strengthen my prayers for XeTeX to be ported to HB/Gr2.

-- 
Shriramana Sharma