From: Shriramana S. <sa...@gm...> - 2012-07-24 18:18:13
|
Hello. If I try to attach a reordered vowel sign to its base (to get composite metrics for attachment of further diacritics) it does not work correctly. I think the files will speak for themselves: https://sites.google.com/site/jamadagni/files/temp/krishna-tamil-reordered-attachment-test.zip I hope you people can help. Thanks. -- Shriramana Sharma |
From: Martin H. <mar...@si...> - 2012-07-26 06:27:35
|
Dear Shriramana, > Hello. If I try to attach a reordered vowel sign to its base (to get > composite metrics for attachment of further diacritics) it does not > work correctly. I think the files will speak for themselves: > https://sites.google.com/site/jamadagni/files/temp/krishna-tamil-reordered-attachment-test.zip > > I hope you people can help. Thanks. Congratulations, you have exposed a bug in the graphite2 engine. We will fix it post haste, but in the meantime, to get your font working, ensure that you have at least one class based substitution in your font, even if it's something as stupid as: cCons > cCons (assuming Sharon doesn't optimise that away) For those wanting details, graphite2 will reject a font with no classes. Classes are only used for glyph subsitution (think right hand side of rules). Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2012-07-26 07:18:41
Attachments:
krishna-tamil.gdl
|
On Thu, Jul 26, 2012 at 11:57 AM, Martin Hosken <mar...@si...> wrote: > Congratulations, you have exposed a bug in the graphite2 engine. [bows] 'Twas bound to happen sooner or later, no? ;-) > We will fix it post haste, Nice to hear. > but in the meantime, to get your font working, ensure that you have at least one class based substitution in your font, even if it's something as stupid as: But Martin, what I provided was only a minimal test case. I've now attached the full GDL which has lots of class substitutions. (I presume you can take the rest of the test content from my same link as above https://sites.google.com/site/jamadagni/files/temp/krishna-tamil-reordered-attachment-test.zip.) The offensive part of the GDL that tries to attach a reordrant vowel sign to a consonant (and thereafter attach a diacritic to it, which is however not necessary for the bug to occur) is on lines 200, 208, 209 which are currently commented out. When they are commented out, the rendering is: [reordered_vowel_sign] [consonant] and [reordered_vowel_sign] [consonant_with_diacritic]. Note that the diacritic is not centered over the cluster. The commented-out lines are intended to make it centered over the cluster. When those lines are uncommented, the current buggy rendering is: [consonant] [incorrectly_non_reordered_vowel_sign] and [consonant] [incorrectly_non_reordered_vowel_sign] with the diacritic centered over the cluster. The desired rendering is: [reordered_vowel_sign] [consonant] and [reordered_vowel_sign] [consonant] with the diacritic centered over the cluster. Note that for Tamil script, I can leave the lines commented and thereby ignore the bug since these applications of diacritics are largely hypothetical in Tamil. However when I get around to doing Krishna Devanagari Vedic, where I will need to center Vedic tone markers over the syllable, this bug will surely bite me. As such, it would be much appreciated if you fix this. Thanks! [But IIUC that currently LibO includes a copy of Gr2 in its source tree, and does not link to a shared library provided by an external package, my backporting your future fixed version of Gr2 to my Kubuntu system will not be useful and I will have to wait for a release of LibO to come up! :-(] I suppose you are not bothering yourself with the XeTeX situation because it uses Gr1 and not Gr2. :-( Perhaps I should include in my daily prayers for XeTeX to be ported to HarfBuzz so I can use latest Gr2! -- Shriramana Sharma |
From: Shriramana S. <sa...@gm...> - 2012-07-27 10:50:33
|
Hello Martin and others. I've since filed two bugs which are clearly integration issues of Gr2 into LibO and not problems with Gr2 itself, but while double-checking the bug this thread is about, I come to suspect maybe it's a problem with Gr2 after all and not with LibO-Gr2-integration. Please find test material at https://sites.google.com/site/jamadagni/files/temp/krishna-tamil-reordered-attachment-test-3.zip Note the terminal output (which you can check on your system): <quote> $ gr2fonttest -codes font-has-ai-attaching.ttf b95 bc8 bxc8 Text codes b95 bc8 pos gid attach x y ins bw chars Unicode 00 95 1@655,0 7.7 0.0 1 30 1 1 bc8 bc8 01 65 -1@0,0 0.0 0.0 0 30 0 0 b95 b95 Advance width = 19.0 Char Unicode Before After 0 0B95 1 1 1 0BC8 0 0 </quote> Looking at the last two columns, it would appear that the reordering is correctly done, since the input order is B95 BC8 whereas the output order is BC8 B95, but observe the x positions! B95 is at x=0 and BC8 is at 7.7. Surely BC8 should be at 0.0 because it has been reordered to go before B95?! Again a recap: The input sequence is B95 BC8. BC8 VS_AI is reordrant and goes before B95 KA. So entering the positioning table (see gdl-has-ai-attachment.gdl) the glyph order is BC8 B95. Line 200 is intended to attach the preceding BC8 (which is a vowel sign) to the following B95 (which is a consonant) because I want to use their composite metrics in the next pass. Lines 208 and 209 in pass 2 attach a following combining mark above the cluster of KA + VS_AI. They function correctly. The problem is created at line 200 which is however syntactically and logically correct -- it seems to be the processing of this command that is faulty. Perhaps the processing assumes that an attached-to glyph will always precede an attached glyph? -- Shriramana Sharma |
From: Martin H. <mar...@si...> - 2012-07-27 13:53:12
|
Dear Shriramana, > Looking at the last two columns, it would appear that the reordering > is correctly done, since the input order is B95 BC8 whereas the output > order is BC8 B95, but observe the x positions! B95 is at x=0 and BC8 > is at 7.7. Surely BC8 should be at 0.0 because it has been reordered > to go before B95?! The problem arises because you do not sufficient specify how the attachment should occur. You only specify that the vowel should attach to the consonant, but you do not say where the attachment should occur. Where no attachment position is specified, the assumption is that the child is sequentially positioned after the parent. If you change your attaching rule to this: gVS_AI { attach { to=@2; with=point(advance.x, 0m); at=point(0m, 0m)} } clsCons; You will find that it works just fine. Alternatively, you could always attach the consonant the vowel ;) Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2012-07-27 17:10:52
|
On Fri, Jul 27, 2012 at 7:22 PM, Martin Hosken <mar...@si...> wrote: > The problem arises because you do not sufficient specify how the attachment should occur. You only specify that the vowel should attach to the consonant, but you do not say where the attachment should occur. Where no attachment position is specified, the assumption is that the child is sequentially positioned after the parent. I'll try this tomorrow, but even if it works, the behaviour without this trick you describe is not true to the documentation. On p 37 the documentation says: <quote>Sometimes it is desirable to attach glyphs **without moving them from their normal positions**. The author may want to obtain the metrics for a sequence of glyphs even though they are not visually attached to one another. This can be done using attachment without specifying the attach.at and attach.with attributes.</quote> [emphasis with asterisks mine] Now please don't tell me that the documentation should be changed. The documentation is correct and describes exactly what is expected by the user. It is the implementation that should be changed accordingly. Reordering of glyphs should occur only in the subs table and that too only by user request. In the present case they are being visually reordered in the positioning table, and that too as an unexpected behaviour *outside* user request. I realize one could do positive shift on the first glyph and negative shift on the second glyph and hence effectively instruct the system to visually reorder the glyphs even in the positioning table, but I do not see why anyone would want to do so. As it is, either the compiler or the renderer is effectively changing the visual order of glyphs without the user requesting such a change. This is IMHO inappropriate. Please fix this. Thank you. -- Shriramana Sharma |
From: Sharon C. <sha...@si...> - 2012-07-27 19:06:49
|
On 7/27/2012 12:10 PM, Shriramana Sharma wrote: > On Fri, Jul 27, 2012 at 7:22 PM, Martin Hosken<mar...@si...> wrote: >> >The problem arises because you do not sufficient specify how the attachment should occur. You only specify that the vowel should attach to the consonant, but you do not say where the attachment should occur. Where no attachment position is specified, the assumption is that the child is sequentially positioned after the parent. > I'll try this tomorrow, but even if it works, the behaviour without > this trick you describe is not true to the documentation. On p 37 the > documentation says: > > <quote>Sometimes it is desirable to attach glyphs **without moving > them from their normal positions**. The author may want to obtain the > metrics for a sequence of glyphs even though they are not visually > attached to one another. This can be done using attachment without > specifying the attach.at and attach.with attributes.</quote> [emphasis > with asterisks mine] 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. |
From: Shriramana S. <sa...@gm...> - 2012-07-28 17:08:58
|
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 |
From: Sharon C. <sha...@si...> - 2012-07-28 20:24:56
|
On 7/28/2012 12:08 PM, Shriramana Sharma wrote: > 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? 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.) But there is some difference between Graphite1 and Graphite2. Graphite2 automatically adds some guard space for the diacritic, even when the advance-width is zero. Martin and I have just been discussing this difference recently. |
From: Martin H. <mar...@si...> - 2012-07-30 03:07:56
|
Dear Shriramana, > Now please don't tell me that the documentation should be changed. The > documentation is correct and describes exactly what is expected by the > user. It is the implementation that should be changed accordingly. Having reserved the right to modify documentation to describe reality even if that reality isn't what people want to hear, I have checked in a fix so that your unique (I have never known anyone want to do what you want) situation is handled consistently between gr2 and gr1. Now you can go and solve your problem in lots of different ways. Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2012-07-30 04:35:01
|
On Mon, Jul 30, 2012 at 8:37 AM, Martin Hosken <mar...@si...> wrote: > Having reserved the right to modify documentation to describe reality even if that reality isn't what people want to hear, I have checked in a fix Hi Martin -- I hope you have not taken amiss my insistence on a consistent and meaningful behaviour. Sorry if I have done/said anything wrong. You of course have the right to write the source code and documentation in whatever way you think is appropriate, but I am sure you will also listen to users of your library as to what behaviour is expected and what not. > so that your unique (I have never known anyone want to do what you want) I think that's because so far there apparently haven't been many implementations of Indic scripts using Graphite. (Of course you people have done Padauk Myanmar, but AFAIK there are no Vedic texts in Myanmar as there are in *Indian* Indic scripts!) And in Indic scripts, I think it is a fair expectation for vowel signs (positioned in whatever direction of the base) to be attached to consonants. It is NOT a fair expectation for consonants to be attached to vowel signs because that *just doesn't make sense*! :-) I have been banking on Graphite to support me in my work on creating (encodings and) fonts for rare Indic scripts which are not going to be supported in OT in the foreseeable future -- I hope you people are with me on that. > situation is handled consistently between gr2 and gr1. Now you can go and solve your problem in lots of different ways. Well, given that gr1 is practically frozen, I suppose you mean by "consistently between gr2 and gr1" that gr2 no longer assumes that the base is at x=0. Are the changes to slot.cpp seen at http://hg.palaso.org/graphitedev/rev/ad1e222b3b16#l4.1 the changes you refer to? Thanks, and once again, I'm sorry if I said anything wrong. -- Shriramana Sharma |