Libertinus: Implement adding combining macron twice on a letter

[KrasnayaPloshchad]

This combination appeared in Kienning Colloquial Romanized Alphabet, but both Libertinus Sans and Serif have no implemention.

Coping the following strings into LibreOffice Writer:

Ā̄Ā̄Ā̤̄Ā̤̄Ē̄Ē̄Ē̤̄Ē̤̄Ī̄Ī̄Ō̄Ō̄Ō̤̄Ō̤̄Ū̄Ū̄Ṳ̄̄Ṳ̄̄Ṳ̄̄
ā̄ā̄ā̤̄ā̤̄ē̄ē̄ē̤̄ē̤̄ī̄ī̄ō̄ō̄ō̤̄ō̤̄ū̄ū̄ṳ̄̄ṳ̄̄ṳ̄̄ 

Then you’ll get the following results:

[mgavioli]

@KrasnayaPloshchad :

1) in the screen shot, are all glyphs repeated twice? (in the 'ṳ̄̄' case, trice?)

2) Is the difference in how the characters are build? It seems to me that:

• the first A is:
  'A' + U+0304 + U+0304
  and the second:
  'Amacron' + U+0304
• the first A with diaeresis below is:
  'A' + U+0324 + U+0304 + U+0304
  and the second is:
  'Amacron' + U+0324 + U+0304

Correct? Same for the others?

3) What about the 3 'U' with diaeresis below?

[KrasnayaPloshchad]

1. Yes, macron should be looks repeated twice on a base letter, as the 'ṳ̄̄' case.
2. They are work around for an automatically converting in MediaWiki and so on, where converting combiniations into precomposed character. For example, if you input 'A' + U+0304, then it become 'Amacron' after you save it. You can try it in their test wiki.
3. They are also intended to work around such convertion. PS. The base letter of this combination should be U-diaerasis below, but the canonical equivalences are valuable to do for technical purposes.

[moyogo]

@KrasnayaPloshchad Out of curiosity, shouldn’t the double macron be encode as a separate character? Sure, stacking several macrons should work in Libertinus fonts but I would have expected a character like 0347 COMBINING EQUALS SIGN BELOW but above to be used instead of two combining macrons.

[KrasnayaPloshchad]

@moyogo I have asked Unicode Consortium, but they refused to receive such character, they suggest using combining macron twice. Here is their reply:

Hello... Thank you for your interest in Unicode.

For this, you should use two macrons, one on top of the other. Some fonts may exhibit poor rendering, but that is a separate issue from the encoding. The correct sequence is: <0075, 0324, 0304, 0304>.

Examples:

Gṳ̿ing --> Gṳ̄̄ing (default font for this message)

And on Windows 7, various fonts:

Gṳ̄̄ing (Times New Roman)
Gṳ̄̄ing (Calibri)
Gṳ̄̄ing (Georgia)
Gṳ̄̄ing (Gentium Plus)
Gṳ̄̄ing (Gentium Basic)
Gṳ̄̄ing (Verdana)

• The Gentium fonts are freely available from SIL.

I hope this helps.

Regards,
Rick

[KrasnayaPloshchad]

I have tested all those fonts as mentioned above (but not Gentium Basic), they are all works pretty, so I suggest Libertinus fonts should follow them.

[mgavioli]

@khaledhosny : there is a number of issues related to diacritic placement; in addition to this one, at least https://github.com/khaledhosny/libertinus/issues/78 https://github.com/khaledhosny/libertinus/issues/70 https://github.com/khaledhosny/libertinus/issues/69 https://github.com/khaledhosny/libertinus/issues/68 https://github.com/khaledhosny/libertinus/issues/66 https://github.com/khaledhosny/libertinus/issues/65 https://github.com/khaledhosny/libertinus/issues/17 (Cyrillic) and, for Hebrew, https://github.com/khaledhosny/libertinus/issues/107 and https://github.com/khaledhosny/libertinus/issues/106 ; plus some recently closed: https://github.com/khaledhosny/libertinus/issues/118 https://github.com/khaledhosny/libertinus/issues/71 https://github.com/khaledhosny/libertinus/issues/85 and perhaps others as well not evident from their title.

The status of base/mark anchors (and their relationships with pre-composed characters) is quite inconsistent, in some fonts more than in other, but each one has its own quirks.

I see two major routes:

• go on fixing each issue separately, possibly with _ad hoc_ solutions, work-arounds and compromises (as I already had to do in some cases); this will presumably allow to fix a number of issues in a relatively short time, but may leave the fonts even more messy and make any additional fix harder;
• redo the mark system from scratch, revising pre-composed glyphs along the route, learning and borrowing from fonts known for their capabilities in this area (as several SIL fonts); this should fix a number of issues at the same time, leaving the fonts cleaner and easier to update and maintain; OTOH, it is bound to take a much longer time, it is likely to introduce differences in existing glyphs (hopefully for the better, but one never knows...) and to leave the fonts in an unstable state for a while.

Comments, anyone?

[khaledhosny]

Well, option two is the proper fix but it is quite some effort, so it is really up to the person doing the work to choose.

[KrasnayaPloshchad]

I also suggest creating a tool to check font behavior between the same codepoint and different styles.

[KrasnayaPloshchad]

CC @skef

[skef]

To the extent that I have a mental list, combining characters are not off it, but they're pretty far down. Not in priority, just in time order. Best to have final or final-ish glyphs before deciding where things belong above and below them. Serif-Regular and Sans-Regular are in quite good shape, some of the other faces much less so.

Fix the fundamental combining issues and almost all of these individual cases will be solved in the process.

[khaledhosny]

Anyone is free to send pull requests that fix this.

[kopeckyf]

While looking into this I noticed that ī (Unicode 012B, Latin lowercase i with macron) currently has a custom macron which is just a bit narrower than the macron used in the combining char and in other Latin characters with macron.

That would lead to rather awkward lay out when the ī is combined with the combining macron above as requested by OP.

Would there be any issues in replacing the custom-width macron in ī with the usual length?