Have three more versions of multilingual OTFs with Hans, Hant, Korean default glyphs

[GoogleCodeExporter]

NotoSansCJK.otf is multilngual OTF (codepoint complete and glyph complete) with 
the default Japanese glyphs and other locale-variants accessible via locl 
feature. 

Some users are disappointed that 'monolingual OTFs' (  Noto Sans {Korean, 
Japanese, Hans, Hant} ) are not code-point-complete. 

One way to resolve this issue is to have 3 more additional multilingual OTFs 
(code-point-complete and glyph-complete) with the default glyphs set to Hans, 
Hant, Korean.  

Unless I'm missing anything, the CFF table won't have to be changed at all (no 
need to re-subroutinization)  because the CFF will be identical in all 4 
multilingual OTFs. The only difference among 4 (one current and three new) 
multilingual OTFs would be opentype tables (locl), cmap tables, etc. 

The end result would be 4 multilingual OTFs 

1) NotoSansCJKJapanese.OTF  : default Japanese glyph
2) NotoSansCJKKorean.OTF : default Korean glyphs
3) NotoSansCJKHans.OTF : default Hans glyphs
4) NotoSansCJKHant.OTF : default Hant glyphs

Original issue reported on code.google.com by jungs...@google.com on 25 Jul 2014 at 6:54

[GoogleCodeExporter]

Original comment by roozbeh@google.com on 25 Jul 2014 at 7:16

• Changed state: Accepted

[GoogleCodeExporter]

Although the glyph data is identical (for each weight), the CFF tables would be 
different, mainly because the PostScript names are different (this is the same 
reason why the Noto Sans CJK and Source Han Sans fonts cannot share the same 
CFFs).

My counter-proposal to this would be to replace the region-specific OTFs with 
region-specific OTFs that are still subsets of the complete 64K glyph set, but 
have identical Unicode code point coverage. Of course, only the Korean subset 
OTF would include the pre-composed hangul syllables and combining jamo. Thus, 
the Simplified Chinese subset OTF would become only slightly larger (adding 
mainly 2K or so Extension B glyphs). The Japanese and Traditional Chinese OTFs 
would become closer to the size of the Simplified Chinese subset OTFs. I would 
vote for keeping the Korean subset OTFs as-is.

Original comment by ken.lu...@gmail.com on 25 Jul 2014 at 7:28

[GoogleCodeExporter]

I forgot to point out that my counter-proposal would mean that the Simplified 
Chinese, Traditional Chinese, and Japanese subset OTFs would include 
approximately 32K glyphs, which is half of the full 64K glyph set, and would 
still be code-point complete when compared to the multilingual OTFs. What would 
be jettisoned are the pre-composed hangul syllables and combining jamo, which 
represent over 13K glyphs, along with ideographs that are not specific to a 
particular region (almost 15K glyphs).

Original comment by ken.lu...@gmail.com on 25 Jul 2014 at 7:33

[GoogleCodeExporter]

Rationals for #2 (according to Ken) : 
1. Size reduction 
2. Speed up subroutinization 

Jungshik: Given that  four OTFs (that are the source of OTC) are fully 
functional (glyph-complete and codepoint-complete),  we'd prefer to get these 
OTFs as they're (codepoint complete and glyph complete). 

Original comment by jungs...@google.com on 29 Jul 2014 at 11:44

[GoogleCodeExporter]

The four OTFs that are used to build the OTCs will be deployed as separate OTFs 
as part of the first update.

Original comment by ken.lu...@gmail.com on 15 Aug 2014 at 4:15

[GoogleCodeExporter]

This was fixed in Version 1.001.

Original comment by ken.lu...@gmail.com on 14 Sep 2014 at 6:35

[GoogleCodeExporter]

Issue 167 has been merged into this issue.

Original comment by roozbeh@google.com on 3 Oct 2014 at 6:20

[GoogleCodeExporter]

<span lang="zh-tw" sytle="font-family:'Noto Sans CJK';">令</span> shows the 
Traditional Chinese variant of '令' on Firefox. On Chrome, locl feature must 
be enabled with '-webkit-font-feature-settings:"locl"' in css in order to show 
the Traditional Chinese variant. Why is locl feature not enabled by default on 
Chrome?

<span lang="ja" sytle="font-family:'Noto Sans CJK TC';">令</span> shows the 
Traditional Chinese variant of '令' instead of Japanese's on both Firefox and 
Chrome, even if I enabled locl feature in css. Isn't 'Noto Sans CJK TC' 
supposed to be multilingual just like 'Noto Sans CJK'?

Original comment by johnny.s...@gmail.com on 18 Oct 2014 at 11:32

[GoogleCodeExporter]

Never mind the second part of #8. It works sometimes when locl enabled, so it's 
probably the glyph-cache problem 
https://code.google.com/p/chromium/issues/detail?id=420282

Original comment by johnny.s...@gmail.com on 19 Oct 2014 at 3:41

[GoogleCodeExporter]

This can be closed because such OTFs were deployed as part of the Version 1.001 
release.

Original comment by ken.lu...@gmail.com on 22 Oct 2014 at 12:47

[GoogleCodeExporter]

Original comment by stua...@google.com on 4 Feb 2015 at 2:07

• Changed state: Fixed