<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Regarding the standard, and as Jonathan mentioned, it is my understanding that the Hebrew presentation forms are in the Composition Exclusion Table. <a href="http://www.unicode.org/reports/tr15/#Primary_Exclusion_List_Table" target="_blank" style="font-size: 10pt;">http://www.unicode.org/reports/tr15/#Primary_Exclusion_List_Table</a>
<div><br>
</div>
<div>Quoting that URL:<br>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">There are four classes of canonically decomposable characters that are excluded from composition:</blockquote>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><br>
<b>Script-specifics</b>: canonically decomposable characters that are generally not the preferred form for particular scripts.</blockquote>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">...</blockquote>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><br>
</blockquote>
The Hebrew presentation forms fall under the script specifics. See <a href="http://www.unicode.org/Public/6.3.0/ucd/CompositionExclusions.txt" target="_blank">http://www.unicode.org/Public/6.3.0/ucd/CompositionExclusions.txt</a> <br>
<br>
It's striking to me that the presentation forms are both "canonically decomposable", yet "generally not the preferred form", and "excluded from composition." I think that makes sense for the Hebrew presentation forms, because the vowel placement depends on
the additional marks.</div>
<div><br>
</div>
<div>For instance, 05D0 05B8 makes sense as FB2F--there isn't a distinguishable difference. However, once you add meteg (05BD) into the mix: 05D0 05B8 05BD, I can't see how you can render it correctly once it is composed as FB2F 05BD. The vowel is in the wrong
position now; it should be moved over to the right more so that there can be space for the mark under the consonant.</div>
<div><br>
</div>
<div>This situation occurs often enough. It seems that it would occur anywhere that a mark is in the same location as the vowel (such as below the consonant). For various examples, see:<span style="font-size: 10pt;"> </span><a href="https://bugs.freedesktop.org/attachment.cgi?id=78621" target="_blank" style="font-size: 10pt;">https://bugs.freedesktop.org/attachment.cgi?id=78621</a><span style="font-size: 10pt;"> and </span><a href="https://bugs.freedesktop.org/attachment.cgi?id=78614" target="_blank" style="font-size: 10pt;">https://bugs.freedesktop.org/attachment.cgi?id=78614</a></div>
<div><br>
</div>
<div>Would the best way to avoid these compositions be adding a decompose function in hb-ot-shape-complex-hebrew.cc which decomposes the presentation forms when followed (or preceded) by other marks?</div>
<div><br>
</div>
<div>Would checking for GPOS be better for this purpose?</div>
<div><br>
</div>
<div>The more places I see HarfBuzz being used, it makes me sad to see these mark placement issues. I even have used it as a test to see whether they are using HarfBuzz behind the scenes. A friend was showing off how great Hebrew looked on the latest Android.
And indeed it looked much better than earlier versions. Just earlier I had read that Android was using HarfBuzz, so I had him pull up Genesis 1:1. Sure enough, the meteg was out of place on the last word, looking more like <a href="https://bugs.freedesktop.org/attachment.cgi?id=78401" target="_blank" style="font-size: 10pt;">https://bugs.freedesktop.org/attachment.cgi?id=78401</a> than <a href="https://bugs.freedesktop.org/attachment.cgi?id=78400" target="_blank" style="font-size: 10pt;">https://bugs.freedesktop.org/attachment.cgi?id=78400</a> </div>
<div><br>
</div>
<div>I hope there is a better solution than always composing these forms. I'd be happy with only composing when only the one vowel in the presentation form is present and no other marks. That seems to address the needs of older fonts yet not interfering with
the placement of additional marks. I think that would only work within the Hebrew script though.</div>
<div><br>
</div>
<div>Scott</div>
<div><br>
</div>
<div>________________________________________<br>
From: harfbuzz-bounces+scott.fleischman=logos.com@lists.freedesktop.org [harfbuzz-bounces+scott.fleischman=logos.com@lists.freedesktop.org] on behalf of Jonathan Kew [jfkthame@googlemail.com]<br>
Sent: Sunday, February 02, 2014 1:45 AM<br>
To: Khaled Hosny; Harfbuzz<br>
Subject: Re: [HarfBuzz] Hebrew composition to presentation forms<br>
<br>
On 2/2/14 01:13, Khaled Hosny wrote:<br>
> Hi,<br>
><br>
> Someone reported an issue with the hireq placement under the yodh with<br>
> Ezra SIL font[1]. When I checked this, it seemed to be because HarfBuzz<br>
> is composing U+05D9 + U+05B4 to U+FB1D and the font has a glyph for<br>
> U+FB1D that has a not so good placement for hireq.<br>
><br>
> I thought this composition is result of Unicode normalisation, so<br>
> HarfBuzz is doing the right thing, but the comment in<br>
> hb-ot-shape-complex-hebrew.cc:75 indicates otherwise. I’m no very sure,<br>
> but I feel this kind of composition should fits more into fallback<br>
> shaping like done with Arabic and not something to be done<br>
> unconditionally, WDYT?<br>
<br>
This is a difficult call. Note that U+FB1D does have a canonical<br>
decomposition to <U+05D9, U+05B4>; the comment in<br>
hb-ot-shape-complex-hebrew.cc relates only to the fact that these Hebrew<br>
presentation forms are excluded from the composition rules for NFC;<br>
thus, both NFC and NFD representations use the decomposed sequence.<br>
<br>
Nevertheless, the two representations *are* canonically equivalent, and<br>
therefore it's appropriate that they should be rendered the same.<br>
<br>
IMO, this is a font bug in Ezra SIL; if a font has positioning rules for<br>
yod + hireq, and also has a precomposed yod-hireq glyph, the two should<br>
look identical. A font that gives the impression that entering U+FB1D<br>
will result in one appearance, while <U+05D9, U+05B4> will result in<br>
something different, is misleading its users.<br>
<br>
As for what harfbuzz should do: currently, it deliberately uses the<br>
precomposed Hebrew presentation-form glyphs, because there are many<br>
(generally older) fonts out there that lack good (or any) mark<br>
positioning rules, and so decomposed sequences look terrible. Using the<br>
presentation forms gives a much better result.<br>
<br>
However, perhaps we should try to be more sophisticated, and do<br>
something like "compose to the presentation forms if the font doesn't<br>
have GPOS mark positioning; otherwise prefer decomposed sequences".<br>
<br>
JK<br>
<br>
_______________________________________________<br>
HarfBuzz mailing list<br>
HarfBuzz@lists.freedesktop.org<br>
http://lists.freedesktop.org/mailman/listinfo/harfbuzz<br>
</div>
</div>
</body>
</html>