Combining Enclosed Mark ( ⃝ ) is not well supported in noto fonts

[dougfelt]

Copied from notofonts/noto-fonts#718 filed by @c933103

See https://ja.wikipedia.org/wiki/三式潜航輸送艇 , in noto font, the character cannot enclose a hiragana character into it as would have been expected. (The combination: ゆ⃝ )

[dougfelt]

Original poster provided examples of both combining enclosing mark and combining keycaps used with kana and hani in original bug report. Copied below:

@kenlunde what are the issues with supporting this kind of use in CJK?

For instance, http://d.hatena.ne.jp/nonokoo/20111106/1320587095 show a number of instance where the symbol would be used together with some symbol, and it also indicated that these would look correctly on ios, persumably with its default font.

https://twitter.com/search?vertical=default&q=%E2%83%9D&src=typd show numerous usage for the symbol together with arabic, numerous random kanji, hiragana, etc. As of writing the character get used on twitter (click Live tab in the search result) for more than a dozen time per every hour to combine with some random symbol/character that cannot be predicted which mean close to 100k tweets carrying the special symbol per year. And I don't know what font twitter used but text displayed correctly on my Win 7 with default setting. Similar usage level is also seen on weibo http://s.weibo.com/weibo/%25E2%2583%259D?topnav=1&wvr=6&b=1

It's also used in album names like http://rateyourmusic.com/artist/%E2%96%B2%E2%83%9D_%E2%96%B2%E2%83%9D_%E2%96%B2%E2%83%9D , and people use it for twitter handle and such https://twitter.com/c_ues

Win8's IE can also partially display that effect despite with some inperfect rendering.

Cambria and Cambria Math font support enclosing of other characters.

https://www.google.com.hk/search?q=%E2%83%A3&rls=com.microsoft:en-US&biw=1280&bih=929&source=lnt&tbs=lr:lang_1zh-CN%7Clang_1zh-TW&lr=lang_zh-CN%7Clang_zh-TW&sa=X&ved=0ahUKEwiWnO_PosrNAhXEr48KHTgsDbs4ChCnBQgU Some example usage about other enclosed characters

[kenlunde]

The character in question, U+20DD COMBINING ENCLOSING CIRCLE, is supported in Adobe-Japan1-5 and greater Japanese font resources as CID+16328, and such font resources number in the hundreds, and possibly over one-thousand. This is the first report of an issue with the glyph for this particular character. I would like to get confirmation that at least one environment supports this character with expected results, and if so the name of the font being used, before considering any tweak to the glyph in Source Han Sans / Noto Sans CJK.

[c933103]

https://images-2.discordapp.net/eyJ1cmwiOiJodHRwczovL2Rpc2NvcmQuc3RvcmFnZS5nb29nbGVhcGlzLmNvbS9hdHRhY2htZW50cy8xOTE3MDkwNDU2NDY2ODgyNTYvMTk3OTA5NzEzNDAzMzc5NzEzL0lNR18xMzkzLlBORyJ9.tQmLoFj8p_FVnLcttvi2Md39Xeg.PNG On iPhone with iOS 9.3.2

[kenlunde]

It shows up differently (and better) in Safari on macOS:

[c933103]

@kenlunde nevertheless the hiragana yu still stay in circle. And here is screenshot from another iphone https://images-2.discordapp.net/eyJ1cmwiOiJodHRwczovL2Rpc2NvcmQuc3RvcmFnZS5nb29nbGVhcGlzLmNvbS9hdHRhY2htZW50cy8xMTgzMzk5NjQxNTU5ODU5MjAvMTk3OTE5MDg3MTY1MTc3ODU4L0lNR18zNzU4LlBORyJ9.kTtrpnFnOWOobUTwKGVFxBZKWJ0.PNG

[kenlunde]

The fact that Safari on macOS, along with whatever iOS is using as a browser (I don't use an iPhone), is handling U+20DD as expected, but that Chrome and Firefox do not, suggests that Apple is supporting U+20DD, but that Chrome and Firefox do not.

[c933103]

@kenlunde after further investigation, it is suspected that the font that can support the symbol itself does not support kana in itself despite it can enclose the kana properly, and since the combination include a kana, Firefox and Chrome would refuse to use the font that only support U+20DD but not the kana to render the font. So if the kana supporting font is merged with a font that support kana then it shall be able to be rendered correctly on both browsers.

[c933103]

Ah and also, the fact that safari/chrome able to combine U+20DD with kana by using when kana does not exist in the font used to display U+20DD shows that you don't need to consider each characters individually when making a font for 20DD that would support the feature? @kenlunde

[kenlunde]

I am not aware of any particular requirement that the glyph for U+20DD must be present in the same font as the glyphs for the characters with which it interacts, but that really depends on the browser.

[c933103]

I was talking about the particular implementation of the two browsers. It work on IE and Safari because it is not required to be in same font

[kenlunde]

This suggests that Firefox and Chrome have work to do.

[dougfelt]

If the mark comes from a different font, then it needs to have the right size and left side bearing to properly overhang the character(s) it encloses, unless the rendering system is not using the glyph and instead drawing its own enclosing circle.

[c933103]

but can Noto be the font that make the symbol work on other softwares that
already allowed it to work with some other nonfree fonts? Instead of
relying in other possibly nonfree fonts
2016/08/04 6:52 "dougfelt" notifications@github.com:

If the mark comes from a different font, then it needs to have the right
size and left side bearing to properly overhang the character(s) it
encloses, unless the rendering system is not using the glyph and instead
drawing its own enclosing circle.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#72 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABdGLcSkI_LflWWdnX29fvh6eCNsJMh7ks5qcRvCgaJpZM4I-Boo
.

[jungshik]

I agree with @dougfelt.
I don't know what kind of magic Safari uses to support 'encircled Kana' when combining enclosing circle (U+20DD) comes from a font other than a font with characters being enclosed. It's also possible that Safari just draws a circle around a glyph when U+20DD comes after a character.

Anyway, Chrome and Firefox (at least for now) do not do either of them.

@c933103: As @dougfelt said, the metrics of enclosing circle should depends on the metrics of characters being enclosed. So, we're not talking about a single enclosing circle glyph but many !.

[jungshik]

Given all the above, it'd be much simpler to make Noto CJK to support them. Because virtually all CJK characters are single width, it'd require only a couple(?) of different glyphs (we're short on glyph slots) by adjusting the position of U+20DD as necessary (in GPOS).

[kenlunde]

After having given this issue more serious thought, it's a can of worms at best, and potentially a red herring. I'll explain.

In the context of a CJK font, the primary use case for U+20DD is to enclose CJK characters, which typically fill the em-box, and are almost always full-width. The exemplar character that is used in this issue is U+3086 ゆ HIRAGANA LETTER YU, whose glyph, especially its upper-right and lower-right corners, does not extend toward the corners of the em-box. However, the glyphs for typical ideographs, along with most Korean hangul syllables, do have shapes that extend to the corners of the em-box, and would require either 1) a glyph for U+20DD that is larger than the em-box, in order to fully-enclose the glyph, which will affect line-layout metrics in potentially unpredictable ways; or 2) forced scaling of the glyph for the character being enclosed, using the center of the em-box as the origin of the scaling, to ensure that that glyph is fully-enclosed in the glyph for U+20DD.

I noted earlier in this issue that Adobe-Japan1-5 includes a glyph for U+20DD. I failed to point out that Adobe-Japan1-4, which was issued earlier, also includes a rather rich set of glyphs that are pre-annotated with U+20DD in the CID range 10234 through 10501. The glyph for the U+20DD–annotated U+3086 is at CID+10401. See Adobe Tech Note 5078 for more details.

[hrhatada]

This Combining Enclosed Mark problem happens on the Noto Sans font, too. See #782(Combining enclosing box causes TOFU). I wonder if this is the case the fonts side fix, or we should request Chrome/FF to support as Safari.

I created a sample file to see the Latin char Combining Enclosed Mark and Japanese ones. Source code is here. You can see the "... do have shapes that extend to the corners of the em-box ..." as kenlunde pointed above even for some Japanese Hiragana chars.

[c933103]

Just found that if setup correctly then Firefox and chrome can also display this.
Step 1: Install babelstone han (http://www.babelstone.co.uk/Fonts/Han.html)
Step 2: Change the default font of firefox and/or chrome to babelstone han
Result: Expected result can be seen in Firefox/Chrome on this issue but NOT on that wikipedia page.

Therefore, I believe the reason why it is rendered correctly in IE/safari but not firefox/chrome in earlier tests was that when the webpage use noto font, IE/safari know that noto does not support this and thus used the character from other font that can support the combination, whereas IE/chrome does not check this
If my interpretation is correct, then these symbols should be within the same font as those characters intended to display in order for chrome/firefox to display them correctly?

[kenlunde]

The glyph for U+20DD COMBINING ENCLOSING CIRCLE in the BabelStoneHan.ttf font has a zero-unit width and is positioned before X=0, so it will superimpose the glyph of the character that precedes it.

[kenlunde]

Please try this special version of NotoSansCJKjp-Regular.otf that uses a zero-width glyph for U+20DD, and also makes the appropriate adjustments for vertical writing ('vmtx' overrides and 'vert' GPOS feature), so please try it in environments that are known to Do The Right Thing™, such as HarfBuzz. Adobe apps don't handle this well, in particular in vertical writing, which is a separate issue.

[kenlunde]

The above test font also makes the same changes to U+3099 COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK and U+309A COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK, for both horizontal and vertical. Like U+20DD COMBINING ENCLOSING CIRCLE, their glyphs are positioned to the left of the origin (X=0) and are zero-width. Those changes are to accommodate horizontal writing. For vertical writing, the 'vmtx' table overrides shift the glyphs 1000 units up and set their vertical advances to zero (0). The 'vert' GPOS (not GSUB) feature then shifts their glyphs 500 units to the right.

Note that these changes to the glyphs and treatment of U+3099 and U+309A does not affect the handling of the small number of pre-composed kana glyphs that are supported by the 'ccmp' GSUB feature.

[acuteaccent]

(half-joke)

One solution for this would be to propose to encode ゆ in a circle (named CIRCLED HIRAGANA YU) in Unicode. As its usage is attested, there is a higher chance for it to be encoded. U+321F or U+32FF would be good.

[kenlunde]

While it would not be an easy sell, such a proposal may be accepted by the UTC. A lot of evidence would be needed. U+32FF would be the better of the two code points.

[kenlunde]

Note that U+20DD COMBINING ENCLOSING CIRCLE is supported in Noto Serif CJK since Version 1.000, and in Noto Sans CJK since Version 2.000.

[davelab6]

Fixed :)