Mark anchor in component not working with mkmk in some cases

I have this setup: /amacron which is a composition of /a + /macron, mapped to U+0101. All good. The macron has a “top” anchor for mkmk. However, when I try the text U+0101 U+0301 (combining acute) the acute is not positioned correctly on anchors. The /acutecomb is a component instance of /acute which has a “_top” anchor:

Interestingly, if I copy the “_top” anchor from the /acute component into the /acutecomb instance, it works as expected:

Am I just wrong to assume mark anchors works via components? (It seems to work in most other cases, so maybe it’s a “max composition level” limitation?)

I’m using fontmake to compile the font.

Here’s a copy of the font source (with a Glyphs tab open reflecting what’s in the screeenshots above):

What versions of Glyphs is this?
I recently changed something that could cause this.

But I would recommend a different setup: The accents without the “comb” should not be used as components, and shouldn’t contain anchors. So basically have the outline and components switch between macro and macroncomb.

Glyphs 3.1.2 (3151)

“But I would recommend a different setup: The accents without the “comb” should not be used as components, and shouldn’t contain anchors. So basically have the outline and components switch between macro and macroncomb.”

Interesting! I’ll try that. What about other composites that uses /…comb as components, for example say /macronacutecomb = /macroncomb + /acutecomb, would I have the same problem there?

I very much prefer to put the anchors in the canonical /macron glyph for two reasons:

  1. It is easier to remember to update the anchor when the design changes
  2. It is error prone (from a human perspective) to work with zero-width glyphs like /macroncomb (things like double-clicking components and just plain preview is finnicky)

What do you mean? Your setup should ideally be as follows: Draw your path-only (/lowest-level component) accents in you comb accent glyphs, such as macroncomb. Then add them as automatically aligned components to the legacy codepoints, such as macron. You only ever need to update anchors in your drawings.

It is generally a very bad idea to use anchors in composite glyphs, as they don’t move together with the components if those change their sidebearings.

Why do you have them set to zero width? This is not necessary. They are set to 0 on export. I recommend using a fixed metrics key (such as =40) for both sides on all comb accents (as well as all non-exporting components, as a general rule):

Left: glyph macron.
amacron is composed of a and macroncomb.

When making composite comb accents, also use the comb accents. As a general rule, you want to use those glyphs as components that are the lowest on the composite foodchain, if that makes sense. Using nested components always leads to problems.
Specifically for composite comb accents, you will often actually want to draw modified components, I recommend either of the following:

  • Make them path-only, hand-drawn. This is the safest approach, but annoying if you reuse the same small component for composite accents.
  • Make duplicates such as acutecomb.small, set them to non-exporting. Use those to make your composite comb accents. This is useful as you can re-use them in multiple composite accents. Remember to set your component side bearings to a fixed metric, so that they don’t move around.

I think we are saying the same thing:

I.e. I want to keep my paths & anchors in one place. Not, say, paths in /foo and then anchors in /foocomb that has a component instance of /foo.

Woah! I had no idea! How reliable is this in your experience? (I’d assume it’s implemented via Unicode data, i.e. if a glyph is mapped to a codepoint classified as “combining”, the glyph’s width is zeroed by the font compiler.)

Thank you for an insightful and thorough reply :•)

I might be misinterpreting your screenshot above, where you have your anchor selected. It looks to me like you have the anchor in a glyph which has an acute as a component (the filled grey outline). Am I mistaken?

I can’t give you a properly informed answer, as I don’t know how it’s done, Georg will have to answer that. But I’ve never experienced it not working, in multiple years of working with Glyphs.

Another question regarding the “auto-zeroed” combining glyphs: How do you make combining glyphs that doesn’t have custom composition for all combinations align properly? For example, say I have /slashshortnosp U+0337 but no ccmp mappings for /n /slashshortnosp. With the “auto-zeroed” approach, I end up with this:

My understanding is that a “best effort” fit is the only solution here, so I place my combining glyphs centered on the /n (picked it since in the font I’m working on, /n has average advance width.) It looks like this:

Or perhaps that’s just something you decide to not solve for?

In the first screenshots, I’m showing the actual setup/design. Notice how the rightmost screenshot—where an instance is used—contains no anchors:

In my second screenshots I’m showing that if I copy-paste the _top anchor from the component into the glyph using it as an instance, the final compiled font (with mkmk) works as expected:

So, the latter here is “a bad workaround”

Like already mentioned, I highly recommend using comb glyphs as the base for everything. Spaced glyph shall only exist and not be used for combining accented glyphs nor used in mark/mkmk feature (spaced diacritics are not meant to be combined). And comb glyphs can stay spaced during the design phase; it’ll be set to 0 on export anyway.

The uni0337, officially slashshortcomb in Glyphs, is intended for lslash/Lslash ( if you want a separate design for L), not n with slash. The positioning is done via the ‘center’ anchor by default; hit command+U and you will get the intended anchor.

1 Like

Took me a while but I’ve converted most of my accent glyphs to use the *comb glyphs as components with anchors in them and others (like /acute) to use an instance of the corresponding comb glyph.

Works like a charm. Thank you everyone!