<div dir="ltr">Well, the source of the problem here is trying to show something that has a compatibility decomposition with its decomposition. I believe compatibility decomposition should be ignored when displaying stuff. If the font doesn't have a glyph for trademark symbol, I definitely prefer to see A™ rendered as A{tofu}, instead of ATM. The first tells me something is unsupported. The second tells me something is OK, when it's not.<div>
<br></div><div>Now, if HarfBuzz wants to continue displaying something other than the .notdef glyph when nothing in the font chain supports a character, it should watch the interactions of the characters.</div><div><br></div>
<div>A similar problem occurs in complex scripts with compatibility decompositions. For example, U+0678 ARABIC LETTER HIGH HAMZA YEH decomposes to [dotted] YEH+HIGH HAMZA, which apart from resulting in a totally incorrect display ordering and appearance of dots, breaks the joining after the yeh.</div>
<div><br></div><div>While UTC makes sure such interactions act the same way with canonical decompositions, compatiblity decompositions are just left as potential hints for people who want to do loose matching. They are often incomplete, and sometimes plain wrong (and left wrong, with the assumption that nobody would use them except for hints about a character's identity or in simplified security- or matching-related use cases). If you do compatibility decomposition for anything, keep a note about that and watch interactions with things around it very carefully.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 22, 2013 at 4:54 PM, Behdad Esfahbod <span dir="ltr"><<a href="mailto:behdad@behdad.org" target="_blank">behdad@behdad.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">James,<br>
<br>
Thanks for testing!<br>
<div class="im"><br>
On 13-12-22 07:46 PM, James Cloos wrote:<br>
> Try rendering 1⅖ with hb-view.<br>
<br>
</div>Very good point.  Indeed, this happens because U+2156 has a compat<br>
decomposition to <0032,2044,0035>, so the fact that it was separated from the<br>
previous digit is lost in the expansion.<br>
<br>
One way to work around this is to intercept those decompositions and insert a<br>
ZWSP before them.<br>
<br>
Roozbeh, WDYT?<br>
<div class="HOEnZb"><div class="h5"><br>
> With a numr/dnom font I get the same as 12⁄5, rather than the same as 1​2⁄5,<br>
> as I’d expect.<br>
><br>
> (Note the U+200B ZERO WIDTH SPACE after the 1 in the latter string.)<br>
><br>
> I’m at 76fff252.<br>
><br>
> Pango-view also renders that string wrong, though differently wrong.<br>
><br>
> -JimC<br>
> --<br>
> James Cloos <<a href="mailto:cloos@jhcloos.com">cloos@jhcloos.com</a>>         OpenPGP: 1024D/ED7DAEA6<br>
> _______________________________________________<br>
> HarfBuzz mailing list<br>
> <a href="mailto:HarfBuzz@lists.freedesktop.org">HarfBuzz@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/harfbuzz" target="_blank">http://lists.freedesktop.org/mailman/listinfo/harfbuzz</a><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
behdad<br>
<a href="http://behdad.org/" target="_blank">http://behdad.org/</a><br>
</font></span></blockquote></div><br></div>