Combining character combines with the following character

[dscorbett]

Font

NotoSansSymbols2-Regular.ttf

Where the font came from, and when

Site: https://noto-website-2.storage.googleapis.com/pkgs/NotoSansSymbols2-unhinted.zip Date: 2018-04-03

Font version

Version 2.000;GOOG;noto-source:20170915:90ef993387c0

Issue

The dotted circle can combine with a preceding combining character, but it should only combine with a following combining character.

Character data

⃣◌ U+20E3 COMBINING ENCLOSING KEYCAP U+25CC DOTTED CIRCLE

Screenshot

[nizarsq]

I can see there are changes in the way how 20E3 combining with 25CC (Comparing with the screenshot provided in the bug) but I think still not combining correctly; 25CC should be higher to be in the middle. The other issue both 20E3 and 25CC shifted to the left. @dscorbett any opinion?

[dscorbett]

That test shows Noto Sans Symbols but this report is about Noto Sans Symbols2.

[nizarsq]

[simoncozens]

Currently things are considerably worse:

But if you think about it the whole situation is completely problematic. The enclosing keycap symbol has no width and is centered with one half below the zero advance and one half after. But even if we tried to do anything better, Noto Sans Symbols contains very few characters on a keyboard that this character could combine with - no alphanumerics or punctuation characters. So as a glyph for creating things which look like keyboard keys, it's useless. We have two options:

1. Give up on being a combining character, make it full-width, and let people use it to "paint" keyboard-like glyphs by overlapping text boxes in vector graphics editors or whatever.
2. Push it entirely to the left, make it a bit bigger, so that it (purely by accident) encloses the Latin subset in full builds.

IMO option two is the least bad, but neither are particularly great.

[dscorbett]

A third option is to remove it from this font and add it to fonts like Noto Sans that include all the base characters to support it properly.

[verdy-p]

The dotted circle is NOT required to be used with a following combining character. It is a symbol by itself, so it is suitable for being embedded by an enclosing keycap. Ideally, it should support the combinations with an enclosing keycap, the dotted circle and another combining character, so that we can get the expected presentation of a keycap showing a combining character, for used with keyboard layouts or in documentations:

Various character layouts (notably Indic, Arabic, Hebew) allow inputing combining characters directly without generating precombined characters, i.e. without using a "dead key" input method, pressing the combining character key before the base letter (or space or dotted circle) to generate precombined characters or combining sequence input, only after the base character has been pressed).

So I'd support the 3-character sequences combinations needed for keycaps for standard Hebrew, Arabic and Indic keyboard layouts: these combinations may use any base character, not just the dotted circle, e.g. a space, an underscore, or an horizontal rectangle, used on various physical keyboards (most Latin keyboards using "dead key" input methods assume an invisible base "space", but Arabic, Hebrew and Indic keyboards don't use the "dead key" method but enter their combining diacritics directly and so the glyph for the keycap should display the dotted circle (except a few frequently used precombined characters, such as HEBREW SHIN WITH SHIN DOT or SIN DOT which may have their own dedicated key in some extended keyboards, that can be presented in a 2-character sequence with the enclosing keycap symbol and the precombined character, whereas the basic layouts for "standard" physical keyboards don't have such extension and should then display the dotted circle in a 3-character sequence for its keycap symbols).