<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Tom,</div><div><br></div><div>If I try your rtf with a simple test then it looks OK to me (see png).</div><div>hb-view --output-file=m.png --font-size=100 minimal.ttf aoèièi</div><div><br></div><div>this is hb 0.9.21 with ot shaper</div><div><br></div><div>Rolf</div><div><img id="d4f9c83c-5f87-4bf4-b531-b1bb779fac84" height="126" width="292" apple-width="yes" apple-height="yes" src="cid:04742084-C2E7-4E01-B307-E3C0F922B851@fritz.box"></div><br><div><div>On Oct 7, 2013, at 1:13 AM, <a href="mailto:tom.programs@gmail.com">tom.programs@gmail.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I am just beginning to try Harfbuzz, but I am writing to you because I think that I might have found incorrect behavior when I have both a contextual chained substitution and a contextual chained positioning.<br><br>The problems occur when I have the following two rules:<br>1 Substitute ["e"] with ["o" "e"] when preceded by an "a" (context: { ["a"] | } )<br>2 Position the mark ["gravecomb"] anchoring it to the ["e"] when the mark is followed by an "i" (context: { | "i" } )<br><br>What I think I should see when I type ["a" "e" "gravecomb" "i" "e" "gravecomb" "i" ] should be something like [aoèièi] <br>What I see is more like [aoeˋièi] (the first "gravecomb" is not anchored to the "e")<br>I used the characters "a", "e", "i", "o", "gravecomb" (U+0300) but the problem is not specific to those characters and persists even in right to left scripts. I found while examining the font SBLHebrew and the string "קוָ֣".<br><br>I built a very minimal font that reproduces this problem with the latin characters I used for the example. I put online the Fontforge source <<a href="https://www.dropbox.com/s/a78cypqv3jgmaex/prova.sfd">https://www.dropbox.com/s/a78cypqv3jgmaex/prova.sfd</a>> and the ttf <<a href="https://www.dropbox.com/s/5hq1c5mdg4isvzo/minimal.ttf">https://www.dropbox.com/s/5hq1c5mdg4isvzo/minimal.ttf</a>><br><br>However, the fact that the problem is reproduced almost exactly on Uniscribe, and even in the Proofing tool of MS VOLT makes me wonder if it is a bug or not. The problem is not present on the shaping system of ConTeXt Mark IV and on Apple's TextEdit, so it is even more mysterious for me.<br><br>I also put the link of the (IMHO correct) rendering of Fontforge <<a href="http://s23.postimg.org/8w44n9b3v/Screenshot_from_2013_10_07_00_55_45.png">http://s23.postimg.org/8w44n9b3v/Screenshot_from_2013_10_07_00_55_45.png</a>> and of the rendering of hb-view <<a href="http://s14.postimg.org/p02lzc29t/Screenshot_from_2013_10_07_00_58_32.png">http://s14.postimg.org/p02lzc29t/Screenshot_from_2013_10_07_00_58_32.png</a>> (in order to render it with "hb-view --language=dflt --features="calt,kern" '/home/mint/Desktop/minimal.ttf' aèièi", be aware that the è is composed of two characters, U+0065 and U+0300, because the software tends to convert this sequence to the single U+00E8 character). The problem is not with the spacing (in my font the "gravecomb" has nonzero width, but it's a mark, so its width is somewhat undefined) but with the fact that the first accent is not attached to the first "e".<br><br>--<br>Tom<br>_______________________________________________<br>HarfBuzz mailing list<br><a href="mailto:HarfBuzz@lists.freedesktop.org">HarfBuzz@lists.freedesktop.org</a><br>http://lists.freedesktop.org/mailman/listinfo/harfbuzz<br></blockquote></div><br></body></html>