Be aware..

[Tarobish]

Digit in the whole Arabic scripts are written from left to write (kerning)

[graphicore]

I did not do anything different than with Jomhuria. Does it work out? Kerning Arabic numbers is pretty much broken in OpenType. I think different shapers behave differently here. So, if it's ok with harfbuzz (Firefox, Chrome) I'd just leave it as it is.

[Tarobish]

This way they just works fine but with the kerning they are perfect if there is no way to kern them so be it as it is :)

On Feb 4, 2016, at 11:03 AM, Lasse Fister notifications@github.com wrote:

I did not do anything different than with Jomhuria. Does it work out? Kerning Arabic numbers is pretty much broken in OpenType. I think different shapers behave differently here. So, if it's ok with harfbuzz (Firefox, Chrome) I'd just leave it as it is.

— Reply to this email directly or view it on GitHub https://github.com/Tarobish/Katibeh/issues/81#issuecomment-180003788.

[graphicore]

There is a comment about this: https://github.com/unified-font-object/ufo-spec/issues/16#issuecomment-120036174

money quote:

In short, HarfBuzz and Uniscribe handle those differently. Easiest is to ignore them for now. Or if you wish, remove them from the kern pairs. I can't recommend one way or another as the "right" way at this time.

[Tarobish]

So ignore them :)

On Feb 4, 2016, at 12:48 PM, Lasse Fister notifications@github.com wrote:

There is a comment about this: unified-font-object/ufo-spec#16 (comment) https://github.com/unified-font-object/ufo-spec/issues/16#issuecomment-120036174 money quote:

In short, HarfBuzz and Uniscribe handle those differently. Easiest is to ignore them for now. Or if you wish, remove them from the kern pairs. I can't recommend one way or another as the "right" way at this time.

— Reply to this email directly or view it on GitHub https://github.com/Tarobish/Katibeh/issues/81#issuecomment-180040311.

[khaledhosny]

What is the issue with kerning Arabic digits? I don’t recall having an issue with that (but I do it not that often).

[graphicore]

See the quote above. Behdad said Uniscribe and Harfbuzz behave differently and there is no right way to do it.

[khaledhosny]

Have you actually tested it (writing kerning directly and not using the pathetic excuse for font formats that is UFO)? At worse it would boil to something similar two how the subtending marks were handled to work in both engines.

[graphicore]

and not using the pathetic excuse for font formats

lol: https://xkcd.com/378/

[graphicore]

At the moment kerning for arabic numbers is defaulting to "mixed" kerning pairs, which is due the lack of a proper recommendation . like:

lookup for arabic: pos uni0663 uni06F0 <-70 0 -70 0>;

and

lookup for latin: pos uni0663 uni06F0 -70;

Have you actually tested it

No. I have actually no kerning pairs with Unicode BIDI types AN-AN in my kerning data anyways, as far as I can see. It would do the same thing as above however—due to a lack of a better proposal. I have a very clear announcement that kerning in for Arabic numbers in OT is FUBAR and that there is no right way to do it. I could test it and still have no right way to do it. I don't waste my time with that crap.

writing kerning directly and not using the pathetic excuse for font formats that is UFO

Again, about this. I write FEA code from UFO kerning.plist input. There is no excuse about UFO, the thing is that there is apparently not one correct way to do this in OT-Kerning (via FEA or directly via magnetized needles on the hard drive). I'm a bit upset because the excuse was never about UFO and you calling it "pathetic" clearly demonstrates that you did not bother to read it up and rather cared to bully around.

How about a constructive critique in the form of "I have made good experiences applying [...] strategy to my fonts".

[khaledhosny]

No criticism was directed to you, sorry if this wasn’t clear.

My criticism is directed to UFO which I think is bad font format (ill-specified, ill-informed, conflicting parts, severely lacking). I don’t mind using tools when they work, for long time I actually used FontForge UI to edit my font features because it actually works and gives my all control I need to specify my layout code, and I switched to writing feature files by hand for reasons unrelated to the capabilities of FontForge UI or file format in handling OpenType layout (which neither UFO nor any UFO editor I know of is a match for it).

My question about whether you tested it or not was truly genuine, I don’t have away to test against Uniscribe right now so I wanted to here your experience and see if there is anything I can help with. Anyway, here is how I have done kerning digits in the past and it worked for me last I tried (but I don’t recall if I tested it against Uniscribe or not and can’t test it now) and I don’t see any reason why it wouldn’t work.

[khaledhosny]

To clarify, digits are always shaped LTR so the complexities of Arabic kerning does not apply to them, and I don’t think there is much a difference between different engines here (but I can be wrong). It would be a problem if you wanted to kern Arabic letters with the digits since it is impossible in the current OpenType model as they will end up in different runs due to the difference in resolved direction (nothing inherent about it though, but just the way OpenType engines are currently designed).

[graphicore]

No criticism was directed to you, sorry if this wasn’t clear.

Ok, no harm done.

My criticism is directed to UFO which I think is bad font format (ill-specified, ill-informed, conflicting parts, severely lacking).

I think I share some of your points there, I could probably add to the list if we were about to make one. But I don't think that there are really better alternatives. When discussions about formats start I think it's very soon obvious that there can't be "the one" format, the holy grail of font formats. So I'm actually thinking that this discussion is flawed. In fact, I couldn't care less how the data is serialized to disk, it's much more important what the data represents and how to move the data around. Essentially I think we should define APIs, similar to the two "pen protocols", and forget about serialization. UFO as a serialization format would speak very little of that API, but for some cases (like Latin fonts, lol) it would be just enough. But this is just a gut feeling, no serious proposal. I don't know if it's a good idea. I may start one day something to get more concrete.

I have done kerning digits in the past and it worked for me last I tried

and

I don’t think there is much a difference between different engines here

Ok, cool, so I will do just normal LTR kerning for AN-AN pairs. However, I don't have any of such pairs in the fonts I'm working on.

@Tarobish did you not kern the Arabic digits with Arabic digits intentionally because of my answer in this issue?

I don’t have away to test against Uniscribe right now so I wanted to here your experience and see if there is anything I can help with.

Using virtual-box we could actually test it in all or some of the Internet Explorers: https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/ This is maybe worth a try. However, I don't have a windows box myself and didn't try it.

[khaledhosny]

(Incidentally I have been downloading that VM for several days now, but at my current internet access availability it won’t finish for few more).

[graphicore]

Uh, that sucks.

[graphicore]

Hmm, I'm at the moment trying to do kerning like this pos uni06F9 uni06F9 -60; for AN-AN, EN-EN and AN-EN etc. kerning. For all scripts and directions I use the same lookup. It seems not to work in Firefox. Instead, the space next to the kern pair is altered. Which is still better than my approach before, this style: pos uni0663 uni06F0 <-70 0 -70 0>; seems to increase the space between the pair!

[graphicore]

To be more specific, In this case pos uni06F9 uni06F9 -60; and RTL text direction the pair seems to be moved to the right, by the amount kerned. I'm getting however some cases where kerning has no effect at all. I wonder if this is an optimization strategy of Firefox, where too small kerning values are skipped.

[graphicore]

The optimization theory is void: pos uni06F8 uni06F9 -150; seems not to be kerned at all but it has a very big value.

[graphicore]

It still looks like some pos rules are just not applied. However, the more complex kerning style for arabic seems to to do the right thing. I was before switching the kerning off, when the numbers moved away from each other, I just had it mixed up in my brain and thought they moved away when switching on facepalm

[graphicore]

Ok, I'm stopping this for now. I tested in Firefox and Chromium. This style pos uni0663 uni06F0 <-70 0 -70 0>; seems to be the right one for these environments.

While I had no visual proof of the above kerning pair (and some others but not all) being applied at all in the mentioned browsers, I have the indication that it's not a problem of the font, by using the hb-shape command:

$ hb-shape --language=ar --features="-kern" Build/Katibeh-Regular.ttf "٣۰"
[uni06F0=1+258|uni0663=0+503]
$ hb-shape --language=ar  Build/Katibeh-Regular.ttf "٣۰"
[uni06F0=1+258|uni0663=0@-70,0+433]

BTW: Harfbuzz changes the glyph order for these inputs to a RTL order (also when --language=ar is not used), even though the digit direction is LTR:

$ hb-shape  Build/Katibeh-Regular.ttf "٣۰"
[uni06F0=1+264|uni0663=0@-70,0+445]

For Latin numbers we get:

$ hb-shape  Build/Katibeh-Regular.ttf "30"
[three=0+406|zero=1+470]

Here the three comes first.

I think this is why the pos uni0663 uni06F0 <-70 0 -70 0>; formula holds true in this case.

Just for reference, I used this live testing document and I had "observable" kerning at the bottom of the table. I used the browser developer tool to switch some kernings in the no kerning column back on, to observe the pairs changing their distance.

[Tarobish]

Perfect :)