[HarfBuzz] [p-c] Perso-Arabic symbols for "year"

[Khaled Hosny]

On Mon, May 28, 2012 at 07:50:55PM -0400, Behdad Esfahbod wrote:
> [CC'ing Khaled and HarfBuzz list]
> 
> On 05/28/2012 06:57 PM, Shervin Afshar wrote:
> > I noticed the same problem with Text Edit, but with NeoOffice using Amiri font
> > I had a bit of success as the string of U+0601 followed by three Arabic
> > numerals—say, ۱۲۳—ended up being rendered as U+0601 encompassing the first
> > numeral in the string and the rest were left out. The same thing happens with
> > other encompassing symbols like U+06DD ( ۝ : ARABIC END OF AYAH).
> > 
> > Also, regarding the limitation of encompassing numeral for U+0601, considering
> > the following OT code:
> > 
> > http://amiri.git.sourceforge.net/git/gitweb.cgi?p=amiri/amiri;a=blob_plain;f=sources/enclosing.fea;hb=HEAD
> > 
> > Does this definition limit the count of possible numerals to be enclosed,
> > say...to three or four?
> 
> It *tries* to limit to four I believe.  Read below:

Four for year sign and three for the others which is reasonable IMO (at
least of end of ayah and footnote sign, not sure about number sign).

> This block:
> 
> feature calt {
>   sub                                              @YearSign @Digits' lookup digit2medium;
>   sub @Digits.medium                               @YearSign @Digits' lookup digit2medium;
>   sub @Digits.medium @Digits.medium                @YearSign @Digits' lookup digit2medium;
>   sub @Digits.medium @Digits.medium @Digits.medium @YearSign @Digits' lookup digit2medium;
> } calt;
>
> Looks completely wrong to me in that it matches the backtrack sequence in the
> wrong order.  Ie, from what I understand, and I can be totally wrong, it
> should have lines like this:
> 
>   sub @YearSign @Digits.medium @Digits.medium    @Digits' lookup digit2medium;
> 
> instead of this:
> 
>   sub @Digits.medium @Digits.medium    @YearSign @Digits' lookup digit2medium;

AFAIK the backtrack coverage has to be in the reverse order, if I do as
you suggest, only first digit will be matched. This have been tested
with FireFox¹ (hb-ng), Pango (hb-old), LibreOffice (ICU) and MS Word
(Uniscribe), so I think it is correct² :) 

> I like how Scheherazade SIL implements this BTW.

I wanted to do it with as fewer glyph variants as possible (was then
obsessed with smaller file size) and Scheherazade’s didn’t work with
LibreOffice last time I checked.

> > Finally, can anyone make any sense of the "hacks" recommended by SIL in this
> > page in terms of what's happening with the Bidi behaviour?
> > 
> > http://scripts.sil.org/cms/scripts/page.php?item_id=ArabicFonts#b78d09ff
> > 
> > Do they work?
> 
> That's what I was explaining before.  Two things:
> 
> 1. You want to force the enclosing sign into the same bidi run as the numbers.
>  Because, as I said, before Unicode 5.1 it was classified as an Arabic Letter
> and hence RTL, whereas digits are LTR.

AFAIK this is no longer an issue, it has been fixed in later Unicode
releases and an up to date software stack should do just fine with no
hacks.

Regards,
 Khaled

¹ only end of ayah not the others, but since they all share the same
  lookup, I suspect it is a Unicode properties issue on FireFox side.

² The last Amiri release had a thinko that didn’t exist in previous
  release which breaks the positioning of the digits, but the substation
  is OK, and is already fixed on master.