fullwidth brackets should be proportional in Korean

[oliviazhu]

Moved from Moved from googlei18n/noto-fonts#120

@roozbehp reported on 6 Aug 2014 at 8:07: According to Denis (@moyogo), the fullwidth angle brackets in the CJK fonts should be proportional for Korean, any recent Korean font (by Sandoll or Yoon Design) would do that.

@kenlunde wrote on on 7 Aug 2014 at 2:11:

Given that an ideal Korean experience with Noto Sans CJK (and, of course, the Adobe-branded Source Han Sans) requires support for the 'locl' GSUB feature, along with proper language-tagging at the character, paragraph, or document level, in order to access the Korean- or CJK-specific forms of proportional-width Western punctuation (the glyphs are aligned to the em-box rather than to Latin features, such as the x-height or cap-height), I would lump this request in with that, specifically that the 'palt' (or 'vpal' for vertical) GPOS feature should be invoked, which will make the glyphs for U+3008 and U+3009 immediately suitable for proportional use. The 'palt' GPOS feature additionally handles other similar character pairs, in case they're used instead of their ASCII (proportional) counterparts. I thus consider the priority relatively low.

@jungshik wrote on on 15 Aug 2014 at 12:34: Blink (and Webkit) have two contents rendering paths. By default, CJK is rendered in a 'simple script' rendering path where most GSUB/GPOS features are not invoked. The majority of documents on the web in Korean will go through that simple script path.

Even if those 'palt' and 'vpal' can be turned on by default in 'Noto Sans CJK Korean' (or 'Noto Sans Korean'), I'm afraid that it might not work for the above scenario.

So, it appears that we need to have separate glyphs for U+3008 ~ U+300B (and potentially more). As we discussed at the meeting, we'll try to come up with a list of characters whose advance widths are different between Noto CJK/Source Han and Korean fonts by Sandoll/Yoon design.

Attached are two screenshots, one with NanumGothic and the other with Noto Sans Korean. They have U+300A and U+300B. The text used is "《로스트》는 평론과 대중"

There's no space between U+300B '》' and '는' (the first character after U+300B), but visually, it looks like there is if Noto Sans Korean is used.
With NanumGothic, there's no such problem.

As I mentioned during the meeting, we can open up glyph slots by removing separate glyphs for Hangul Halfwidth Jamos (U+FFA0 - U+FFCx) and just mapping them to the corresponding nominal glyphs for Hangul Jamos (U+11xx block) or to the corresponding Hangul Compat Jamo (U+31xx block). That way, we can open up ~ 50 glyph slots.

@kenlunde wrote on 17 Aug 2014 at 1:21:

This issue is definitely being deferred for the first update, and I'd prefer to defer it indefinitely because this doesn't seem to be the right way to address the issue, especially for the long term.

Referencing what other fonts do may seem like the right approach, but that is not always a good idea. For those who are interested in this issue, I strongly encourage going through KLREQ: http://www.w3.org/TR/klreq/

What should happen is interaction between the layout engine and fonts, with awareness of the language. Japanese layout engines have matured, and the same thing is happening for Korean. Some characters are best left full-width, such as those in U+30xx, which will allow the layout engine to deal with them consistently.

The problem with the what is being proposed is where to draw the line. Instead, the line should be drawn between what the font specifies and what is expected on the layout engine. That happened for Japanese, and it needs to happen for Korean.

Also, mapping the nominal glyphs for the U+11xx block from the half-with jamo block (U+FFxx) would be a disaster, because combining jamo takes place at the GID level, not character code level.

Again, please read KLREQ carefully. It sets the stage for better Korean layout. What the referenced fonts are doing is ad hoc at best.

@jungshik wrote on 25 Aug 2014 at 10:46:

Also, mapping the nominal glyphs for the U+11xx block from the half-with jamo block (U+FFxx) would be a disaster, because combining jamo takes place at the GID level, not character code level.

I did realize that after writing my comment. However, there'd be no problem if we just remap U+313x glyphs for U+FFxx half-width jamo block. Nobody would care whether or not U+FFxx block uses the same glyphs as U+313x block.

@jungshik wrote on 25 Aug 2014 at 10:51:

Instead, the line should be drawn between what the font specifies and what is expected on the layout engine. That happened for Japanese, and it needs to happen for Korean.

Where has it happened for Japanese? InDesign?

@kenlunde wrote on 25 Aug 2014 at 11:02:

Any application that claims Japanese support for line layout should be able to many of these basis adjustment tasks. Adobe InDesign was one of the first desktop apps to do so, and serves as a benchmark. The fact that JLREQ is emanating from W3C suggests that some web browsers include such support.

What the fonts you have referenced have done is equivalent to jerry-rigging the glyph set, which is something that should be avoided, mainy because it gives birth to legacy issues and concerns.

@kenlunde wrote on 26 Aug 2014 at 2:31:

About mapping the half-width jamo (U+FFxx) to the glyphs for compatibility jamo (U+31xx), while you may may not care, I am guessing that a non-zero number of users will care, which is the reason why I am reluctant to jettison those glyphs. In any case, we'll be discussing this issue in more depth in October.

@moyogo wrote on 28 Aug 2014 at 6:14:

KLREQ is still a draft and does not clearly address spacing of punctuation. There are already some issues with KLREQ that might need to be dealt with to clarify this: http://www.w3.org/International/track/issues/269 Inconsistent spacing http://www.w3.org/International/track/issues/271 Punctuation

@kenlunde wrote on 28 Aug 2014 at 12:16:

Precisely, which is exactly why we shouldn't rush into adding such glyphs to the fonts in case doing so creates a nasty legacy condition.

@behdad wrote on 26 Oct 2014 at 1:50:

Action item for Jungshik to test U+30xx and U+FFxx (proportional versions of ASCII brackets) against a bunch of (15 / 20?) high-quality Korean fonts for comparison.

[dougfelt]

Copied tags and assignee over from original bug report.

@jungshik, you were referenced in the original bug too.

[roozbehp]

/cc @moyogo

[jungshik]

KLREQ is still a draft and does not clearly address spacing of punctuation.

I would not use KLREQ as any trustworthy reference point for our font development at least at this point. Being future-proof is a laudable goal, but we have a problem to solve at hand. It's really unfortunate that we haven't resolved this issue to meet Korean needs.

An apparent space between a closing angle bracket and a syllable (usually case-marker / post-position) as shown in my comment (copied from the original bug and reproduced below) is really bad.

Text in the screenshot:
《로스트》는 평론과 대중 모두에게 좋은 반응을 얻으며

• Angle Bracket in Nanum Gothic

• Angle Bracket in Noto Sans CJK KR / Noto Sans Korean

[jungshik]

About mapping the half-width jamo (U+FFxx) to the glyphs for compatibility jamo (U+31xx), while you may may not care, I am guessing that a non-zero number of users will care, which is the reason why I am reluctant to jettison those glyphs. In any case, we'll be discussing this issue in more depth in October.

I guess the number of "people" who care about U+FFxx half-width Hangul Jamo is precisely 1 in the world. :-)

Those characters cannot be input with any of Korean IMEs on any operating system. The only way to enter them is to use NCR or similar forms of input by code points. They may have been added to the Unicode via Xerox (or some other character sets) perhaps because a pre-KS X 1001 Korean standard (pre-KS C 5601) dating back to 1970's had them. However, virtually nobody uses them (perhaps creative Japanese 'text-artists' may have used in some web pages, but that's not so likely given that lack of font support for those characters).

[KrasnayaPloshchad]

I feel this variant may not so necessary, because in certain typefaces these ankle brackets not proportinal in Korean.

http://www.bilibili.tv/video/av413619/

[jungshik]

@KrasnayaPloshchad I have absolutely no idea what you meant by linking to the document you did.

I surveyed Korean fonts from Sandoll and Yoon Design and they all have proportional glyphs for bracket-like characters.

For Korean, the default glyphs (without any opentype feature invoked) for them should be proportional.

In an unlikely case where somebody wants 'full-width' glyphs for them in Korean fonts, 'the inverse' of 'palt/vpal' (I don't know whether there's a OT feature for that; that is for full-width alternatives) should be added.

@behdad

[jungshik]

Moreover, virtually all the Korean books in my bookshelves have 'proportional' glyphs for bracket-like characters. There's no extra-space when they are immediately followed by a graphic character (Hangul, Hanja, punctuation mark, etc).

See https://photos.app.goo.gl/GYscTD82zJjEvxy62 (I haven't yet annotated them so it'd be a bit hard to find them). I'll annotate them so that it's easy to see where to look.

[kenlunde]

I met with @kojiishi this morning at Adobe, and out of that came a suggestion to use the 'locl' GPOS (not GSUB) feature for handling this. The appropriate 'halt' and 'vpal' (or 'palt' and 'vpal' if proportional is desired) GPOS feature records would be cloned for this purpose.

[jungshik]

Thanks for the update, @kenlunde . I think proportional (as opposed to half-width) is better (so, palt, vpal).

[kenlunde]

In the case of the Source Han and Noto CJK fonts, regardless of whether you specify halt/vhal or palt/vpal, the result is half-width brackets.

[davelab6]

@kenlunde is this tracked upstream in SSH repo?

[kenlunde]

@davelab6 Not necessary, because the "UI suggestion" section of the 'halt' (Alternate Half Widths) and 'vhal' (Alternate Vertical Half Metrics) GPOS features covers such use.

[davelab6]

Got it. @oliviazhu hope that answers your need :)

[davelab6]

This issue seems to still be current, per an internal Google user, so reopening.

The issue is still outstanding (I've just checked that on Android with the latest release of Noto Sans CJK) and it hurts my eyes (and those of other Koreans) whenever I read wikipedia articles (where brackets are heavily used for book/movie/song titles) on Android/Chrome OS. Please, reopen it.

[jungshik]

Got it. @oliviazhu hope that answers your need :)

Note that @oliviazhu just copied the bug from the old bug tracker (code.google.com) to github. It's me who filed this issue. And, this issue is still very much outstanding.

[jungshik]

Thank you for reopening. Please, add back Defect label and drop 'question' label. Thanks !