...macrongrave, ...macronacute issue

Why do composites with …macrongrave/…macronacute use macrongravecomb/macronacutecomb, instead of macroncomb + gravecomb/acutecomb?

That way you can define stacked marks.

Sorry, I don’t follow. Why do I get the second emacronacute, and not the first?
emarconacute.png
Unicode defines emacronacute as 0113 + 0301, whereas FC uses 0065 + 1DC4.

If you don’t want to use e+macronacutecomb, then just provide your preferred formula to get your desired result. These should work just fine:

emacron+acutecomb
or this:
e+macroncomb+acutecomb

Yes, I’m aware of the solution - I was asking why the formula encoded in FC goes counter to Unicode?

It is because it allows you to use a different glyph for two stacked marks. This is something that is rather common; see for example Bahnschrift.

Except COMBINING MACRON-ACUTE isn’t the same as COMBINING MACRON + COMBINING ACUTE, and e+macronacutecomb has different meaning than e+macroncomb+acutecomb or correctly realised emacron+acutecomb. So the choice isn’t purely stylistic and FC shouldn’t use these particular substitutions since the meaning of 1DC4-1DC9 is different than the meaning of a sequence of their “components”. I understand the idea I think - so if a user creates a stacked mark glyph and names it after its parts, FC will use that mark first, if it’s present, and if not, it will use 2 separate marks. Correct?

I am by no means an expert, but from what I understand is normalization does not change the meaning of text.

Yes, that is the logic behind it.

From what I understand, COMBINING MACRON-ACUTE isn’t the same as stacked COMBINING MACRON and COMBINING ACUTE. It has been encoded to represent an entity with a special meaning, distinct from regular diacritic combinations, obtainable via inserting one diacritic after another. Shouldn’t the default FC action reflect the Unicode Standard?

I understand the idea I think - so if a user creates a stacked mark glyph and names it after its parts, FC will use that mark first, if it’s present, and if not, it will use 2 separate marks. Correct?

Yes, that is the logic behind it.

And in principle it’s a great idea and very helpful, but how about excluding from that list of potentially (=based on their names) stacked marks those that already are part of the Unicode standard? So, code-points: 1DC4-1DC9, 1DCB-1DCC?

Consider it done!

Thanks, you’re the best!