Microsoft Uniscribe renderer behaviour for kerning and Arabic marks

Hey all,

a question about the MS renderer.

I’m debugging an Arabic font, and in the sequence رّكك the Shadda on the final Reh “moves” with the kerning between final Reh and initial Kaf. By "moving" I mean as I type Reh + Shadda the mark is placed correctly, but as I continue to type Kaf the kerning between Reh and Kaf is applied, but the Shadda gets "pushed to the right" by as much as Reh and Kaf are (negatively) kerned.


Here a couple of fonts in Microsoft Word for Mac 16.16.5; the bottom one being the font I'm debugging.


I tested further, and to my astonishment it seems that any mark “moves” like this, affected by kerning when its base glyph is kerned against something to follow. In the font I am testing, final Reh and initial Kaf have their overlap kerned, so the Kaf arm slides nicely over the Reh. When I looked how some other fonts avoid the marks moving with kerning I found that e.g. in this example initial Kaf simply had a negative right sidebearing; makes sense to do it like this in the first place.

What does not make sense to me is why the renderer would behave like this. Applying kerning, but pushing the marks above kerned pairs to the side from their original place above the base glyph. Is my font buggy, or is this really the renderer “working as intended”?

Anybody have insights to this or encountered a similar issue with Word or other Microsoft programs?

Comments

  • I'm not sure how your OpenType features are formed but is it possible that the lookup flag in your kerning features is not set to ignoreMarks?
  • Johannes NeumeierJohannes Neumeier Posts: 265
    edited October 15
    I'll definitely double check that, but this happens only in Microsoft programs. Mac, Adobe, Fontgoggles, they all render the kerning and marks without any weird issues. If it were the lookup flag it should happen throughout all programs, I reckon.

    Edit: IgnoreMarks is there, so it's not that.
  • How about changing the order of mark and kern features? Sometimes the order of features can make them work differently across different engines.
  • John HudsonJohn Hudson Posts: 1,932
    Yes, my first thought is lookup ordering. The recommendation I always had from Microsoft is that GPOS should be ordered curs -> kern -> mark -> mkmk.
  • edited October 16
    Thanks All for discussing this issue.
    Hope this post will shed light on the fallacy of auto-controlling of the three variables of dynamic Arabic typefaces, namely kerning, dot-positioning and mark-positioning that go on changing with different letters, ligatures and sizes. That's right: The problems of Arabic Typefaces are solved nowhere save by our unique tool, namely QalamBartar elaborated by the files attached at my Telegram Channel: https://Telegram.org/ > https://T.me/FonJawi/5 .
    Happy exploring with Flowers https://T.me/FlowerCrosswords
  • edited October 16
    Sorry! Doubled post.
  • edited October 16
    Sorry! Doubled post.
  • Huge thanks @Bahman Eslami and @John Hudson - spot on. It didn't even occur to me that their order might matter for the renderer, but I can follow the implicit logic here :|
    I'm using fontmake in this production and it semi-automates the generation of those features. I'll have to do some more debugging to establish if it is something we are additionally doing to the features or if it is an issue with fontmake itself.
  • Either way, order of application of lookups should not differ between shaping engines. Something else is wrong.
  • John HudsonJohn Hudson Posts: 1,932
    Either way, order of application of lookups should not differ between shaping engines. Something else is wrong.

    Yes, it isn't that the different engines are applying the lookups in different order, but that they have different interpretation of the lookups, producing different results depending on the ordering.

  • Simon CozensSimon Cozens Posts: 458
    edited October 16
    If you can subset the font to a minimal set of glyphs to show the problem (ideally with pyftsubset) and attach it to a Harfbuzz issue I can take a look at it.
  • edited October 17
    Samples speak louder than words?!
    With the said couple of fonts, I would like to see how kerning and mark-positioning go if the letter R (ر) in the above sample is replaced with the letter Z (dotted R =ز).

  • @AzizMostafa AzizAli That rather speaks to the quality of the design, but does not help debug the issue I was facing and have since resolved. The mark attachment and kerning for ر and ز are not technically different.
  • edited October 19
    @AzizMostafa AzizAli That rather speaks to the quality of the design, but does not help debug the issue I was facing and have since resolved. The mark attachment and kerning for ر and ز are not technically different.
    Resolved even in case the letter Z (dotted R) comes with Shadda (ـّ) plus additional mark as usually encountered so, as shown in the attached sample in which I have to shift Z down for the top font and apply different kernings for the bottom one, too?

  • Small tashkil can cover a multitude of problems. ;-)
  • edited October 20
    Small tashkil can cover a multitude of problems. ;-)
    Wherever tashkil problem is encountered, I recommend making use of the wide Kaf (ك) shown in this image to one of QalamBartar fonts ( https://Maryamsoft.com/QalamBartar/ ).

  • edited October 20
    Sorry! Doubled post.
  • Johannes, if you want to know whether this display is the result of a problem specific to MS Word, simply paste the same text into TextEdit—macOS has decent OT processing.

    If I were to guess what is happening based on the display, as well as your explanation, I would say that the Shadda is first positioned on the Reh, then kerning is applied to Reh-Kaf, causing the Reh to shift leftward and leave the Shadda behind. 

    To verify what is really happening, test your text & font in the Crowbar application. It will show you which lookups (under which features) have been activated in which order during the substitution and positioning stages. 
  • In my post, the last line should have read:

    ...activated in which order during the substitution and positioning stages.
Sign In or Register to comment.