screwed arabic GPOS-kerning in InDesign ME CS3

[yanone]

hi everyone,

i'm working on latin/arabic fonts and since half a year i'm running into a kerning problem when using normal GPOS/kern-feature kerning in InDesign ME CS3 5.0.4.
(a solution could be to use a flat kern-table, but i run into other problems with feature syntax and FL, so i want to use FDK, read more in the http://forum.fontlab.com/adobe-fdk-for-opentype-afdko/add-kern-table-to-ot-font-via-sfntedit-t348.0.html on the other list.)



first line shows the word without kerning (manually set to 0).

second line shows the word with the applied kerning from the kern-feature. the base glyph of the kerning pair (rah) is shifted to the right, along with its following glyphs. but the rah should stay, and only the following should move (which they did). note: the overall word's bounding box is correct. the kerning value in the text toolbox between the rah and the kaf shows the correct (-124), indicating metric's kerning.

third line: if i manually change the kerning value from (-124) to -124, it suddenly renders correctly. note: the values are exactly the same. one with brackets, one without.


i don't think that it's a bug in indesign, it's already the fourth update (5.0.4). and: flat kern-table kerning works.
i already tried to split the kern feature up into separate lookups for latin and arabic, applying things like script tags and RightToLeft and stuff to it, to no avail. RightToLeft doesn't make sense anyway, because the direction of the kerning is correct. if i manually set the kerning value to +124, the gap increases twofold as it should. also: all settings in indesign like language and writing direction are set correctly.

any ideas?
it seems to work in CS4 (which i can't confirm because i don't have access to it), but since that doesn't run on powerPC macs anymore and my recipients all have CS3, it needs to run there.

many thanks for a hint,
yanone

[tnemeth]

hi there,
although i can't explain the technical background, VOLT's kern2volt utility will do the job for you. i understand that this is not convenient for it is yet another step, but at least it works pretty well and efficiently.
t

[tiro_hudson]

How are you defining your GPOS kern adjustments? For right-to-left text, it is important that the kerns are applied as width and positioning adjustments to the first glyph in a pair, which is different from how left-to-right kerning is usually defined (as a width adjustment to the first glyph).

[Edited to correct reference to first glyph. See further discussion.]

[yanone]

hi tiro_hudson,
i don't really get whet you're saying. in my understanding, kerning exists only as pairs of letters and a value. (A,T=-50). how am i supposed to apply kerning to just one of the two letters (both in fontlab and indesign)?
but please reconsider from my first post: the values are correct, and identical for GPOS and kern-table kerning. only with GPOS the first glyph of the pair is shifted, instead of the second. and with a flat kern table, it works as expected.

[tiro_hudson]

OpenType GPOS kerning -- as distinct from kern table kerning -- is a GPOS pair adjustment. What this means is that, for a given pair, one of more adjustments are made to the spacing and/or positioning of one or both glyphs. This makes GPOS kerning much more powerful than old-fashioned pair-value kerning, although most fonts treat GPOS kerning as if it were simply a translation of pair-value kerning and tools like FontLab and kern2volt convert pair kerning into GPOS kerning.

When text runs left-to-right, the first glyph in a pair is on the left, so kerning is implemented as a width adjustment of the first glyph. For example, a Latin T+a kern would be implemented as, say, a -100 width adjustment to the T, i.e. the right sidebearing of the T is shifted 100 units to the left.

But when text runs right-to-left, the first glyph in a pair is on the right. You might think that the obvious way to implement such kerning is by mirroring what you do for left-to-right kerning, i.e. adjust the width of the second glyph. However, if you do this, only every second pair of letters will be kerned, because the layout engine will treat any first glyph in a subsequent pair that has already been adjusted as a second glyph in a previous pair as already being processed, so it will be skipped.

So the kerning adjustment still needs to be applied to the first glyph, not the second, but now the first glyph is on the right, and if you only adjust the width of that glyph you are affecting the right sidebearing (since all measurements in glyph space are from left-to-right, regardless of the text direction. From your illustration, this is exactly what is happening in your font: the -124 kern is being applied as a width adjustment to the ra, collapsing the spacing on the right side of the letter. The reason why manually setting the kern value to -124 in InDesign ME works is that the application knows how to kern right-to-left text.

In order to correctly kern right-to-left pairs in a font, the GPOS kern lookup needs to 1) adjust the width of the first glyph and 2) apply an equivalent horizontal position adjustment to the same glyph. In the case of your ra+kaf pair, this means you will first reduce the right sidebearing of the ra by -124 units, and then shift the ra -124 units (i.e. to the left).

Now, I honestly don't know if there is a way to do this with FontLab. I suspect there is if you manually edit the OpenType GPOS <kern> feature syntax in the OTL panel; I don't think there is a way to automatically do this during conversion from FontLab kerning to GPOS kerning. The other thing to bear in mind, of course, is that because left-to-right and right-to-left kerning are implemented in different ways, you probably need to maintain separate kern sources for different directions, and it is wise to implement them in separate GPOS lookups (although this isn't technically necessary).

I don't use FontLab for OpenType Layout development, and I'd say that you can't build a fully functional Arabic font using only FontLab.

[k.l.]

Hi Jan,

John's analysis was right. To translate what John said into AFDKO syntax:

(1) Make separate lookups for LTR and RTL kerning.

(2) Inside the RTL kerning lookup, set the RTL lookupflag:
lookupflag RightToLeft
Re "RightToLeft doesn't make sense anyway, because the direction of the kerning is correct" -- unfortunately this is wrong. OT layout tables define kerning in logical rather than visual order, so in your example the 'rah' (to the right) is the first glyph, the 'kaf' (to the left) is the second glyph.

Now two important things to consider:
(a) To work as a proper kerning pair, the GPOS spec expects that the first* glyph of a pair is adjusted rather than the second glyph. This is necessary so that the second glyph of a pair can act as first glyph of another pair. (If you'd adjust the metrics of the second glyph, the layout engine would consider it as consumed and not kern it with a following glyph any more.)
(b) Since, as said in (a), the first* glyph's metrics need to be adjusted even in RTL direction kerning, this means that in an RTL kerning lookup the first=right glyph of a pair needs adjustment of both its positioning and its advance width.

* "First" again is the first in logical order, rather than the left glyph.

(3) Now expressed in AFDKO syntax, (a) and (b) mean that while an LTR pos command looks like this:
pos T a -124;
an RTL pos command looks like this:
lookupflag RightToLeft;
pos rah kaf.init <-124 0 -124 0>;
# more pairs here
lookupflag 0;
i.e. following logical order, the 'rah' is the first glyph, and what the pos command do is: moving the first glyph (mind that the origin is still on the left side!) to the right and decreasing the advance width at the same amount.

Best wishes,
Karsten

[corrected typos]

[gohebrew]

Why kern when you can use GSUBs for a bunch of ligatures?

Once you do it once, it's rather easzy to duplicate it for a whole series of fonts.

I did it successfully for Biblical Hebrew, which makes complex Arabic seem like cheesecake.

[Tags:]

Jump to: Please select a destination: ----------------------------- News and announcements ----------------------------- => Announcements from the forum’s moderators => News from the font industry ----------------------------- Type design and font technology ----------------------------- => Principles of type design => OpenType Layout feature development => Hinting => Font Formats and OpenType => Web font embedding => Font licensing ===> Electronic EULA Abstract (EEULAA) ----------------------------- Education and collaboration ----------------------------- => Work: Offers => Work: Looking for => Education: Offers => Education: Looking for => Typographic Events and Conferences ----------------------------- FontLab products ----------------------------- => News from FontLab => FontLab Studio ===> FontLab Studio Problems ===> FontLab Studio Tips and Tricks ===> FontLab Studio Wish List ===> FontLab Studio Public Preview => Fontographer ===> Fontographer Problems ===> Fontographer Wish List => TypeTool => AsiaFont Studio => TransType => ScanFont => SigMaker => Other Products ----------------------------- Photofont products ----------------------------- => BitFonter => Photofont WebReady => Photofont Start => Photofont ID => Photofont QX => The Photofont technology ----------------------------- Adobe Type products ----------------------------- => Adobe FDK for OpenType (AFDKO) ----------------------------- Apple Font products ----------------------------- => Apple Font Tools ----------------------------- Microsoft Typography products ----------------------------- => Microsoft Font Validator => Microsoft Visual OpenType Layout Tool (VOLT) => Microsoft Web Embedding Fonts Tool (WEFT) => Microsoft Visual TrueType (VTT) ----------------------------- Other products and Python scripting ----------------------------- => Python scripting => FontTools/TTX => Other font-related tools ----------------------------- Special interest groups ----------------------------- => SBL Fonts ===> SBL Hebrew ===> SBL Greek ===> SBL BibLit ----------------------------- FAQ and TechNotes ----------------------------- => OpenType Layout feature development FAQ and TechNotes => Hinting FAQ and TechNotes => Font Formats and OpenType FAQ and TechNotes => Web font embedding FAQ and TechNotes => Font licensing FAQ and TechNotes => FontLab Studio FAQ and TechNotes => Fontographer FAQ and TechNotes => TypeTool FAQ and TechNotes => AsiaFont Studio FAQ and TechNotes => TransType FAQ and TechNotes => ScanFont FAQ and TechNotes => SigMaker FAQ and TechNotes => BitFonter FAQ and TechNotes => Photofont WebReady FAQ and TechNotes => Photofont Start FAQ and TechNotes => Photofont ID FAQ and TechNotes => Photofont QX FAQ and TechNotes ----------------------------- Archive (MSN Groups) ----------------------------- => Archive: Old FontLab forum ===> Archive: FontLab Tips and Tricks ===> Archive: FontLab Bugs and Problems ===> Archive: FontLab Wish List ===> Archive: FontLab Announcements => Archive: Old Microsoft Font Validator group => Archive: Old Microsoft VOLT group => Archive: Old Microsoft VTT group ===> Archive: VTT Downloads ===> Archive: VTT Support ===> Archive: VTT Suggestions => Archive: Old Microsoft WEFT group ===> Archive: WEFT III ===> Archive: EOT for Email => Archive: Old SBL Fonts group ===> Archive: SBL Hebrew ===> Archive: SBL Greek ----------------------------- Various ----------------------------- => fontlab.com — the FontLab website => forum.fontlab.com — this forum => Other Topics