fullwidth angle brackets should be proportional in Korean

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by roozbeh@google.com on 6 Aug 2014 at 8:07

[GoogleCodeExporter]

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.

Original comment by ken.lu...@gmail.com on 7 Aug 2014 at 2:11

[GoogleCodeExporter]

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. 

Original comment by jshin@chromium.org on 15 Aug 2014 at 12:34

Attachments:

• angle_bracket_in_NanumGothic.png
• [angle_bracket_noto korean.png](https://storage.googleapis.com/google-code-attachments/noto/issue-120/comment-2/angle_bracket_noto korean.png)

[GoogleCodeExporter]

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.

Original comment by ken.lu...@gmail.com on 17 Aug 2014 at 1:21

[GoogleCodeExporter]

> 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.

Original comment by jshin@chromium.org on 25 Aug 2014 at 10:46

[GoogleCodeExporter]

> 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?  

Original comment by jshin@chromium.org on 25 Aug 2014 at 10:51

[GoogleCodeExporter]

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.

Original comment by ken.lu...@gmail.com on 25 Aug 2014 at 11:02

[GoogleCodeExporter]

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.

Original comment by ken.lu...@gmail.com on 26 Aug 2014 at 2:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by moy...@gmail.com on 28 Aug 2014 at 6:14

[GoogleCodeExporter]

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.

Original comment by ken.lu...@gmail.com on 28 Aug 2014 at 12:16

[GoogleCodeExporter]

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.

Original comment by behdad@google.com on 26 Oct 2014 at 1:50

[behdad]

cc @roozbehp @jungshik