Dramatic bug in Hebrew kerning?

Glyphs
1

A while ago, I noticed that Glyphs applies kerning to Hebrew letters wrongly in Edit windows when in LTR mode. I figured I should only ever work on Hebrew in RTL mode, so I did that. For instance, here’s some kerning between /resh-hb and /samekh-hb, which use the kerning classes of /O and /T, respectively:

Screen Shot 2016-03-19 at 13.59.13.png1490×560 40.9 KB

It appears to be working, but note that the info dialog displays the /rekh-hb’s kerning class as empty (its right-side value), whereas it should be «T» (its left-side value). That’s an annoying bug for editing, but at least the results are as desired. Right…?

Unfortunately, when I plug this font into Pablo’s font testing page (tab «World Scripts» on the main page), I get the following:

Not only is the kerning not applied where needed, but it looks like it’s been applied between /tav-hb and /resh-hb instead. Argh!

Is this a bug in Glyph’s implementation of kerning, or is it the browser misinterpreting the kerning rules?

2

I just tested it and it worked for me in Indesign and the test page in Safari. Can you send me the file (.glyphs and the final font)?

3

Try the file I sent you recently… I think I might have solved the problem by making independent kerning classes for Hebrew, though, as Rainer just taught me to.

It would probably be worthwhile to decouple kerning classes between scripts upon export… Should be pretty straightforward…

4

Have code for that but it produces bigger GPOS Table and thus will hit the subtable overflow earlier. I didn’t check for classes between LTR and RTL glyphs. For now you will need to have separate classes for both directions.

5

Oh, but it’s OK to share groups within a direction?

6

I would still try to be on the safe side and separate them. Tosche’s Metrics scripts can help you with it.