Custom LSB & RSB for Zero Width Mark Attachment

Glyphs
1

I am currently working on IPA support. The /breveinverteddoublecomb spans across two glyphs.

994×640 70.3 KB

The glpyh gets automatically transformed on export into a zero-width mark, as described in the Mark Attachment tutorial:

1002×664 52.2 KB

This works if the mark-feature is enabled:

But with the mark-feature disabled or unsupported, the position is incorrect:

Whereas an other font with IPA support, Gentium Plus, continues to work without mark-feature, because its /breveinverteddoublecomb is centered within the zero-width glyph:

1042×816 62.4 KB

Is there an option or a special anchor name to tell Glyphs where to place the mark within the zero-width frame? I would like to position my /breveinverteddoublecomb on export like Gentium does.

2

Did you find some software where that would actually be a problem?
You can move the outline a bit to the right.

1 Like
3

No, I mainly want to change it such that it works in as many environments as possible, even in cases which I have not tested. The Gentium approach seams more stable in that regard.

This works! As I understand it, the right edge of the edit-glyph becomes the center of the export-glyph. That leaves me with the left half of the glyph to double-click in the edit view, which is enough for me.

Thank you for your quick reply!

4

My understanding was that double-width marks don’t get anchors or mark code, they just float between letters. @GeorgSeifert I think we discussed this fairly recently, wasn’t the idea to put a non-exporting #collapse anchor in there to tell Glyphs where to collapse the sidebearings?

5

My use-case for anchors is to place the mark directly above the glyph pair, like in Minion 3:

858×412 40.6 KB

1 Like
6

I see! This allows its width to be distributed proportionally between the t and s. What happens in cases with a wide first letter and a narrow second letter, or two wide letters, does it still work well?

7

Minion 3 does not perform well with wide or narrow letters:

05
051788×356 64.7 KB

Gentium does not use anchors, which places the mark perfectly centered, but the height of the mark is fixed:

17
171802×356 66.5 KB

The width of the mark does not change in either font. Perhaps contextual substitution could be used to change the width of the mark.

8

I just realised that there is a special anchor that does something very similar: “*origin”. It is meant for components that are used as pieces to build glyphs (stems, serifs …). I added support of it in the component alignment code.

3 Likes
9

Contextual substitution does indeed allow to change the width of the mark:

2133×729 202 KB

I also placed a _paircenter anchor in the visual center of the mark and paircenter anchor to the right edge of character-glyphs to retain the exact centering:

1181×574 64.8 KB

I like the idea of an *origin anchor for marks.

10

The double combining marks are not meant to go into mark/mkmk, hence the mark attachment anchor is a bad idea. I would add contextual positioning features which raise the glyph accordingly. Typically you’ll be able to define two, maybe three default heights to which you will be able to raise the mark, with e.g. a simple <0 200 0 0> for raising by 200 units.

1 Like
11

That sounds like a great idea, but it does not work in my testing. Here is what it looks like in FontGoggels with HarfBuzz:

1542×520 176 KB

With following kern-feature code:

# low glyphs (m, n, ...)
pos @Low breveinverteddoublecomb' <0 -200 0 0> @Low;
# medium height glyphs (i, t, ...)
pos @Low breveinverteddoublecomb' <0 -100 0 0> @Med;
pos @Med breveinverteddoublecomb' <0 -100 0 0> @Low;
pos @Med breveinverteddoublecomb' <0 -100 0 0> @Med;
# high glyphs (f, esh, ...)
pos @Low breveinverteddoublecomb' <0 100 0 0> @High;
pos @Med breveinverteddoublecomb' <0 100 0 0> @High;
pos @High breveinverteddoublecomb' <0 100 0 0> @Low;
pos @High breveinverteddoublecomb' <0 100 0 0> @Med;
pos @High breveinverteddoublecomb' <0 100 0 0> @Low;
# test
pos a b' <0 -200 0 0> c;

I would expect that /breveinverteddoublecomb is moved down 200 units, because /n is a member of @Low, but as you can see in the ∆Y column in the screenshot above no adjustment is applied.

Moving /b between /a and /c however does work. I’m new to GPOS features (my feature code above is based on the AFDKO GPOS LookupType 7 examples), so maybe I am missing something obvious.

12

Perhaps try:
pos @Low breveinverteddoublecomb' @Low <0 -200 0 0>;

Also, perhaps worth checking any lookupflags are zeroed before these rules. Marks might be being ignored from a previous lookup.

The other possibility might be that the kern feature is built to ignore marks. Try moving these GPOS rules to the Mark or Dist feature, or somewhere else.

1 Like
13

I just learned what lookupflag 0; means and it works! Thank you all for your support!

2332×252 78 KB

14

And you also can move horizontally. If a wide letter is on the right, move it a few units to the right. With a small letter, move it the other way. And as the movements are incremental, both sides will push or pull a bit.

15

Thank you for the pointer. Currently I am using 9 mark glyphs – {Small, Medium, Large}² – which serves me well.

1960×1272 175 KB

Three glyphs are redundant (SM–MS, SL–LS, ML–LM) and could be simulated by horizontal kerning. Removing this redundancy would probably make the feature code more complex, but the exported files would be cleaner and smaller. I will look into it.

(All 9 glyphs use a single _part glyph, which makes managing them a joy.)