Aha! It appears we are bumping into bugs (or at least compatibility issues) left and right with these fonts, font format and fontforge.

There's a bug report specifically about this missing character when viewed in FontForge.

https://github.com/fontforge/fontforge/issues/1831

When I open the OTF font in FontForge v20120731, I see that there is no unicode number associated with 量 (0x91cf) {1}. However, I do see the character there. When we convert to TTF, it is indeed dropping this character because of the missing number (probably the purpose of the cid map).

It looks like the FontForge project has been rebooted {2}, so I grabbed the spec file and rebuilt the RPM (actually, I used the one from Fedora Rawhide). When I use FontForge v20140813, I see a unicode number associated at the location of the 量 glyph. However, the glyph doesn't look right...then again I don't know what it should look like and how much variation it can have. Perhaps you can try the latest FontForge, open the OTF, navigate to 0x91cf (Ctrl+Shift+> to bring up navigation dialog), and see if it looks acceptable to you.

My general conclusion is that we are hitting the bleeding edge with the Noto Sans CJK fonts and it might be a better strategy just to use CJK fonts that have working TTF files until the situation stabilizes. You have suggested using Droid Sans, and as I mentioned M+ is also an option. I'm partial to M+. I verified it does have the 量 glyph.

On another topic, it seems like the strategy for bold and italic in CJK is to use different font weights. Is that accurate? If so, then we should probably map the bold and italic to the font weights provided with these fonts (M+ for example has 7 weights).

Indeed, lots to learn. That's why it's important to document as we go.

Cheers,