mark to mark "active" on ligatures -- clearly a bug

[arno]

I added a mkmk-lookup to an Arab font, because I want two (above) marks on the same letter to readjust.
But what I get, is that on a ligature, where these (above) marks sit on different component letters, they are rearranged in a way I did not intend.
Is mkmk meant to work that way?
Or is it a mistake in VOLT? Or in uniscribe?
Can I restrict mkmk adjustment to simple letters and the a component of a ligature (instead of the whole ligature)?
Arno

Postscriptum days later: I tested this in a Latin font. It is the same.
When I tell two marks to slightly adjust when sitting on the same letter, they make the same "adjustment" when sitting on two components of a ligature (I created a dotless-i+dotless-j ligature for testing).

[tiro_hudson]

The issue here is probably the categorisation of the ligatures in the GDEF table and the mark-to-ligature handling. I'm guessing that you have not classified the ligatures as such, nor identified the number of components in each (this can be done in the VOLT glyph data editor). This means that when a ligature forms it s treated thereafter as a simple glyph, and the marks are not associated with the individual component letters but instead are grouped together after the ligature, and hence become subject to <mkmk> positioning.

Using lam_alif as an example, what you want to do is:

a) set the glyph category in the glyph data editor to 'Ligature' and the number of components to '2';

b) create a mark-to-ligature lookup in your <mark> feature and provide positioning for marks relative to each component part of the ligature; note the 'Component' drop down in the upper right corner of the GPOS window, which is used to specify independent anchors on different parts of the ligature.

[arno]

thanks for the reply, but
I have done all this from the beginning -- otherwise the marks on the ligatures would be awful.
Proper definition, and different anchors in markLig lookup,
but when there is a mkmk lookup   the marks on the different components interact
-- and on one letter with two (above) marks  the mkmk lookup does nothing.

Maybe, I make a mistake in the mkmk lookup? I use pair adjustment.

[tiro_hudson]

I use pair adjustment.

That may be the problem: a <mkmk> lookup is normally an anchor attachment, just like the <mark> feature.

[arno]

In deed, when I use anchor attachment in mkmk, it works fine.

But where is it stated that pair adjustment in mkmk is wrong?

And why should marks interfere across components in a ligature anyway.
I think it is a mistake in VOLT.

And -- more importantly -- anchor attachment in mkmk does not achieve what I want:
when I have two marks above the same letter I want them both to readjust:
one moving up, the other down or/and one moving to the right, the other to the left,
but all I can get with anchor attachement is that the first stays where is sits when alone
and the second one moves relative to the first one.

[BobH]

I've never tried pair adjustment in this scenario, but to make sure: you should have the "Process Base Glyphs" option checked on the lookup.

If it really can't be made to work (and this would be a bug in Uniscribe, not in VOLT), then a work-around is to continue to use anchor-based positioning, but you can use a lookup that has a context to choose different attachment points for the same mark.  So, for example, mark A normally attaches to base B at Anchor 1, but when mark A is followed by mark C (i.e., there is a following context of mark C) then A attaches to B at Anchor 2 instead. Clumsy but it does work -- I've used this to change the positioning of a marks under Lam-Alef when there are marks under both Lam and Alef.

Bob

[arno]

Yes, I have the "Process Base Glyphs" option checked on the lookup.

So, it IS a BUG. Maybe the guys from MS can unbug VOLT or UniScribe?

> So mark A normally attaches to base B at Anchor 1,
> but when mark A is followed by mark C (i.e., there is a following context of mark C)
> then A attaches to B at Anchor 2 instead.

You would have to work with EXCEPT in the one context, wouldn't you?
As you say; clumsy, but at least it works.
Anchor in mkmk on the other hand, does not really work in Arabic.
For the Arabic script marks have no fixed position
-- as Tom Milo likes to point out, even the diacritical points have no fixed position.
There is limited space between the letter and the upper limit of the font.
One likes to put the mark into the center of that space,
but if you have to take care of a second mark you have to put it into the (low left) corner.
If you do that only when a second mark follows (see above), okay,
but if you do this just in case, it is aesthetically not acceeptable.

Any chance to stop mark-pair-adjustment working across components soon?
(It seems that nobody   who dares to speak   ever used this lookup. -- ??)

[Sergey Malkin (Microsoft)]

Mark-to-something is the only type of lookup that tracks which component of the ligature mark belongs to. Everything else just sees linear sequence of glyphs, if mark on first base had been pushed out when two bases form a ligature. Pair adjustmentnt will only see Base1Base2Ligature+mark1+mark2 for any of these combinations:

Base1 Mark1 Base2 Mark2,
Base1 Mark1 Mark2 Base2,
Base1 Base2 Mark1 Mark2

Mark-to-* lookup sees the same sequence, but layout engine tracks source of each mark and knows which component of the ligature it should be attached to.

There is no reason why marks over two bases should not interact, it is frequently required. But having such interaction  complicates contextual lookups and/or requires additional substitutions.

[arno]

Thanks!
So, do I understand you correctely:
there is no way to have mark-to-mark pair substitution ONLY valid for ONE base at a time?
Do I have to achieve what by want (two marks sitting on one base at a certain distance to each other)
by substitution (mark, mark > mark-ligature)?
Or is there a way to achieve what I want by mk2mk?

>Pair adjustmentnt will only see Base1Base2Ligature+mark1+mark2 for any of these combinations:
>Base1 Mark1 Base2 Mark2,
>Base1 Mark1 Mark2 Base2,
>Base1 Base2 Mark1 Mark2

It looks to me that in sequence 1 (Base1 Mark1 Base2 Mark2) the two marks should not make the mk2mk adjustment
     (even if a base1-base2-ligature existents in the font),
in sequence 2 (Base1 Mark1 Mark2 Base2) they should do mk2mk on base1,
and in sequence 3 (Base1 Base2 Mark1 Mark2) they should do the same on base2 or on the ligature, if there is a base1-base2-ligature.

Does this look reasonable to you?
Is it feasible to differentiate according to input sequence?

>There is no reason why marks over two bases should not interact, it is frequently required.

Could you give some examples.
Just as for "my case" I propably have to make a mark+mark-substitution,
I thought one could solve most cases of marks on ligature by anchor positioning on the components.
But of course, I am ignorant of most scripts out there.

[Sergey Malkin (Microsoft)]

I've seen this in Arabic fonts, when marks were placed on different heights in context of marks placedover surronding base letters. I also recall that John's SBL Hebrew font is doing something like that.

[arno]

It does not make much sense for Arabic fonts.
For a font that is used often with all marks (qur'an, poetry, schoolbook) you put the marks on different heights by mark-on-ligature with different anchors on different components.
And if -- assuming occasional use of marks only -- you want to have a
"normal" position of the mark when on the other component of the
ligature there is no mark, and an "extra" position if there is a mark
after all, this destroys the optimal positions defined in the mark-on-ligature lookup.
This is exactly the reason I think it's a bug. My fine tuning of two marks interferes with the proper normal placement.

I do not see why one would not profit from differentiating according to input order.

[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