Closed GoogleCodeExporter closed 9 years ago
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
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
关 (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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
roy...@gmail.com
on 18 Jul 2014 at 8:33