Narrowed glyphs in Noto Japanese

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Show 「关门复甩」 with Noto Japanese
2.
3.

What is the expected output? What do you see instead?
Narrowed "关" and "复", "门" doesn't look correct, the left-bottom "leg" of 
"甩" is missing.

What version of the product are you using? On what operating system?
1.0

Please provide any additional information below.
The Simplified Chinese version of those glyphs are correct.

Original issue reported on code.google.com by roy...@gmail.com on 18 Jul 2014 at 8:33

[GoogleCodeExporter]

Thanks a lot for the report.

I cannot confirm 门 (U+95E8), but the choice for the other three is probably 
intentional. The Unicode charts at http://www.unicode.org/charts/PDF/U4E00.pdf 
show a narrower glyph for 关 (U+5173) and 复 (U+590D) in the J[apanese] 
column, and show a glyph with a missing left-bottom leg for 甩 (U+7529).

But there is no J column for 门 (U+95E8).

Assigning to Jungshik, who should know more.

Original comment by roozbeh@google.com on 18 Jul 2014 at 5:18

[GoogleCodeExporter]

These characters don't occur by themselves in Japanese. 关 (U+5173) and 复 
(U+590D) do occur as a component part of a character, for this reason, width is 
ussually narrower as they neeed to fit with other parts. I am not aware of it 
but potentially 甩 (U+7529) can occur as a component part. And if it occcurs 
as a component part, it porbably needs to be narrower. I think 门 (U+95E8) is 
just Chinese and probably does notr occur by itself or as a component in 
Japanese.

Original comment by mo...@google.com on 21 Jul 2014 at 7:53

[GoogleCodeExporter]

关 (U+5173) and 复 (U+590D) are covered in detail here: 
https://github.com/adobe-fonts/source-han-sans/issues/35

The Japanese form of U+95E8, although not shown in the Unicode code charts, is 
the appropriate form for Japanese, which includes a short vertical stroke in 
the top-center of the glyph. The IRG approved this unification.

The Japanese form of U+7529 is also correct for Japanese.

Original comment by ken.lu...@gmail.com on 22 Jul 2014 at 5:53

[GoogleCodeExporter]

The responses from momoi and ken cover the issue. It's not a bug.

Original comment by stua...@google.com on 23 Jul 2014 at 1:18

• Changed state: Invalid

[GoogleCodeExporter]

re:#2 the problem with 门 (U+95E8) is that this character is exclusively used 
in Simplfied Chinese. The Japanese form glpyh is very different from the 
Chinese form, it almost never used anywhere, and it is unfamiliar to Chinese 
native readers.

However the Noto Sans CJK treats Japanese as its primary display locale unless 
it is overridden by system locale or HTML lang attributes (see also b/17303065 
where "门" becomes a problem). I think it would make more sense to remove the 
Japanese form.

Original comment by hshi@chromium.org on 4 Sep 2014 at 8:44

[GoogleCodeExporter]

Actually the bug you refer is only indirectly related to this. The fact that 
the html in that bug is not properly tagged by language is the problem and 
would be in any instance where the browser has to guess what language to use 
for a block of text. If you removed U+95E8 from the Japanese cmap then you 
would have other characters that would be wrong for Simplified Chinese. You 
can't remove all the characters from the Japanese cmap that overlap with 
Simplified Chinese. 

Proper language tagging is the best solution. Alternatively, one could use the 
TTC font file and specify which specific font inside that file to use - e.g. 
the one for Simplified Chinese.

Original comment by stua...@google.com on 4 Sep 2014 at 10:14

[GoogleCodeExporter]

Stuart, I politely disagree. Proper language tagging is of course the right way 
out of this, but not everybody can tag everything, and not every system. A 
better default is very nice to have. Tagged language can always choose the 
right glyph.

CC-ing Jungshik for a second (really sixth) opinion.

Original comment by roozbeh@google.com on 5 Sep 2014 at 2:18

• Changed state: New

[GoogleCodeExporter]

Convinced that we shouldn't do this based on offline communication from Stuart. 
I was missing the context. The bug is about Noto Sans Japanese, not Noto Sans 
CJK. Using Noto Sans Japanese with no language tag is a good enough signal that 
the Japanese form should be selected.

Original comment by roozbeh@google.com on 5 Sep 2014 at 2:40

• Changed state: WontFix

[GoogleCodeExporter]

See http://crbug.com/408199 as to why this is observed on Chrome OS. 

Original comment by jshin@chromium.org on 5 Sep 2014 at 7:07

[GoogleCodeExporter]

See  https://code.google.com/p/chromium/issues/detail?id=411407 to resolve this 
issue by improving the fallback font selection in Blink. 

Original comment by jshin@chromium.org on 5 Sep 2014 at 9:32