Need Noto Sans CJK font instances with 'fixed-width' Latin 'default' glyphs in the OTC packagie

[GoogleCodeExporter]

Recently, Noto Sans CJK fonts were added to Chrome OS ToT and M38 branch. 
However, we couldn't remove 'Motoya Gothic Monospace' fonts (they're actually 
dual-width fonts [1]) for Japanese because Noto Sans CJK has proportional Latin 
glyphs and cannot be used when 'monospace' is requested in CSS. 

Fixed-width Latin glyphs are included in Noto Sans CJK, but they're only 
available via hwid(?) OT feature.

With a new tool available for moving the CFF table from one font instance to 
another, it'd be relatively easy to create a font instance with 'fixed-width 
Latin' glyphs as the default.  (we have to add new cmaps and gpos/gsub tables 
for each 'fixed-width' instance). 

With them (4 of them for each region/locale) added to Noto Sans CJK OTC, Chrome 
OS can save about 15MB.  

[1] http://crbug.com/399080

Original issue reported on code.google.com by jshin@chromium.org on 27 Aug 2014 at 5:31

[GoogleCodeExporter]

Original comment by jungs...@google.com on 27 Aug 2014 at 5:32

[GoogleCodeExporter]

I just finished preparing the necessary UTF-32 CMap resources for this.

Original comment by ken.lu...@gmail.com on 28 Aug 2014 at 2:30

[GoogleCodeExporter]

Original comment by roozbeh@google.com on 28 Aug 2014 at 5:06

[GoogleCodeExporter]

Although I prepared four UTF-32 CMap resources with 44,649 mapping, about 100 
of which are different than the original versions, because it was easy to do, I 
have a counter-proposal for you to consider, which may work, and would be much 
more efficient, and potentially cleaner.

What if I create a language-agnostic UTF-32 CMap resource that maps only ASCII, 
along with U+00A0 for good measure because it shares the same glyph as U+0020, 
to the half-width glyphs in the 65,535-glyph CFFs, and add that as a fifth OTC 
font instance, perhaps named "Noto Sans CJK HW ASCII <weight>" or something 
similar? As long as font fallback is being used, as long as this fifth font 
instance is ordered before any of the four other font instances, the half-width 
glyphs will be used in lieu of their proportional versions. This avoids 
including a lot of unnecessary 'cmap' table baggage (the 'GSUB' and 'GPOS' 
tables would have been the same as the corresponding non-HW font instances, 
because they are GID-based, not code point–based).

Please give this some thought, and let me know whether this could work for the 
desired scenario or purpose.

Original comment by ken.lu...@gmail.com on 29 Aug 2014 at 12:11

[GoogleCodeExporter]

Issue 171 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 184 has been merged into this issue.

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