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

Behdad Esfahbod behdad at behdad.org
Mon May 28 16:50:55 PDT 2012

[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:

This block:

feature calt {
  sub                                              @YearSign @Digits' lookup
  sub @Digits.medium                               @YearSign @Digits' lookup
  sub @Digits.medium @Digits.medium                @YearSign @Digits' lookup
  sub @Digits.medium @Digits.medium @Digits.medium @YearSign @Digits' lookup
} 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;

I like how Scheherazade SIL implements this BTW.

> 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.

2. It's not clear whether the OpenType rules should expect an LTR glyph
sequence here, or RTL.

Hence the two described hacks, to force all LTR, or force all RTL.

Neither works with current harfbuzz-ng of course, since we always flip Arabic
to be RTL before applying lookups.  I have to consult the OpenType list to
decide how we want to resolve that.


> On Mon, May 28, 2012 at 3:25 PM, Behnam Rassi <behnam at me.com
> <mailto:behnam at me.com>> wrote:
>     Actually from what I see, in OS X there is no possibility to even test the
>     fonts for year sign behaviour. The year sign is simply ignored and when
>     you actually input it in Text Edit, it doesn’t show. I copy&pasted from
>     Text Edit to Mellel and the character reappeared. Mellel is incapable of
>     supporting its OT behaviour but it does show the character. I didn’t test
>     Open Office and others. I don’t know if Adobe products can support it but
>     any application on the Mac which relies on Mac Core Text engine (Nisus,
>     NeoOffice etc.) will likely be incapable of showing the character to begin
>     with! (I only tested OS X and Mellel though)
>     -b
>     On 2012-05-28, at 12:00 PM, Connie Bobroff wrote:
>>     A couple points: Shervin found it didn't work on Mac. It may simply be
>>     he'd also put a space or input it incorrectly like I did the first try.
>>     Shervin, please try again!
>     -- 
>     http://persian-computing.org/
>     http://groups.google.com/group/persian-computing/
> -- 
> http://persian-computing.org/
> http://groups.google.com/group/persian-computing/

More information about the HarfBuzz mailing list