Ignoring mark to mark anchors for a specific base glyph

I have baseA glyph with mark1 and mark2 anchors. I also have markA with mark1 and mkmk anchors, and markB glyph with mark2 and mkmk anchors. Normally when markB follows markA it will be positioned relative to it using the mkmk anchor. However, this is undesirable when the base is baseA as markB will clash with it. So what I want to do is to always position markB glyph using the mark2 when the base is baseA and ignore the mkmk anchor.

There is also a complication because there might be other mark glyphs between markA and markB.

Comments

  • John HudsonJohn Hudson Posts: 2,955
    Have you tried simply ordering the [mark2] mark-to-[baseA] lookup — with appropriate mark group filter — after the mark-to-mark lookup? i.e. do the default mkmk position first, and then have the mark repositioned on the base?

    The other, messier method, is to have a second mkmk lookup that repositions [markb] relative to [marka] based on the preceding context of [baseA].

    (I hope I got the identifiers correct, but you probably understand what I'm getting at anyway.)
  • Khaled HosnyKhaled Hosny Posts: 289
    IIUC, reordering the lookups (even if worked) will not give the desired effect since I still want mkmk to be used for all other bases.

    I considered the second option before but tat is messy as you said.

    Now I’m thinking may be trying to fix this with glyph positioning is not the best approach, I can instead have an alternate mark glyph that does not have the mkmk anchor and use glyph substitution with the appropriate context and mark filtering. That is a little messy because of the duplicated glyph, more cleaner than the other approaches.
  • Khaled HosnyKhaled Hosny Posts: 289
    (removing the border around <code></code> block would make the above posts look less messy, the border does not exit in the preview which is a bit misleading as well).
  • John HudsonJohn Hudson Posts: 2,955
    IIUC, reordering the lookups (even if worked) will not give the desired effect since I still want mkmk to be used for all other bases.

    Right, so the secondary mark-to-base lookup, after the mkmk, only contains baseA; all the other bases are already processed in an earlier mark-to-base lookup. Mark positioning is iterative, so you can order lookups to move marks in sequence.

    The GSUB method you suggest is definitely a viable option for this sort of thing. It's what I do in Hebrew fonts for the furtive patah bases.
  • Khaled HosnyKhaled Hosny Posts: 289
    In this particular workflow the mark and mkmk features are auto generated and controlling the order of GPOS lookups would be much harder than adding a GSUB lookup (hello UFO).
  • John HudsonJohn Hudson Posts: 2,955
    I'm highly suspicious of any workflow that makes it difficult to control the order of lookups.
  • Khaled HosnyKhaled Hosny Posts: 289
    Don’t get me started on how wonderful is the world of UFO.
Sign In or Register to comment.