[HarfBuzz] Auto Fractions vs VULGAR FRACTION characters

[Roozbeh Pournader]

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.

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.

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.

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.


On Sun, Dec 22, 2013 at 4:54 PM, Behdad Esfahbod <behdad at behdad.org> wrote:

> James,
>
> Thanks for testing!
>
> On 13-12-22 07:46 PM, James Cloos wrote:
> > Try rendering 1⅖ with hb-view.
>
> Very good point.  Indeed, this happens because U+2156 has a compat
> decomposition to <0032,2044,0035>, so the fact that it was separated from
> the
> previous digit is lost in the expansion.
>
> One way to work around this is to intercept those decompositions and
> insert a
> ZWSP before them.
>
> Roozbeh, WDYT?
>
> > With a numr/dnom font I get the same as 12⁄5, rather than the same as
> 1​2⁄5,
> > as I’d expect.
> >
> > (Note the U+200B ZERO WIDTH SPACE after the 1 in the latter string.)
> >
> > I’m at 76fff252.
> >
> > Pango-view also renders that string wrong, though differently wrong.
> >
> > -JimC
> > --
> > James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
> > _______________________________________________
> > HarfBuzz mailing list
> > HarfBuzz at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> >
>
> --
> behdad
> http://behdad.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20131226/08a80ce4/attachment.html>