Combining marks, .case, and a monospaced font

Glyphs 1.3.17
Monospaced font, in which all glyphs, including marks are width 600.

There are two different issues/questions here:

  1. The combining marks, when exported, end up with a 0 width instead of the original 600, even those that start with comb in their name, e.g., breveinvertedcomb.
    The .case versions keep their width of 600. In a monospaced font, I’d expect them to stay the same; in a proportional font, I’d make them 0 width.

I was trying to find solid info on the recommendation for the width of combining marks when in a monospaced font. One mention by John Hudson from 2009 is here:
Or, has the recommendation for monospaced fonts changed?

  1. Are the mark and mkmk features built automatically, including for the .case variants for uppercase letters? Or do I need to add the positioning features for the .case variants, for now?

A quick test seemed to use the non .case variant and had the combining mark and uppercase glyph overlap. The blog post on Mark to Base Positioning:
seems to indicate that some of the features are generated automatically, now, but didn’t include mention of the .case variants.
[ I’ll admit that I haven’t yet pulled apart the mark features in the exported font to review, yet. So more testing may show what’s needed here. ]

  1. I disagree with John here. Combining marks should under no circumstances advance the cursor position, especially when the mark and mkmk features do not work. That, for me, includes monospaced fonts.

  2. I need to look into that again, but I believe the … accents should be exchanged in ccmp and possibly also in the case feature.

I wonder if the issue, in the past, with monospaced fonts was some programs assuming that a font wasn’t monospaced if any of the glyphs were of a different width. I’m happy to go with whatever works, today. It was just difficult to find an authoritative recommendation for monospaced fonts.

The … marks do end up in the case feature.