Use Noto Sans CJK Version 1.004 in illustrator CC.

[banyan19]

Sorry, I don't speak English. So I print screen.
I have a problem when I use Noto Sans CJK Version 1.004 in illustrator CC.
http://i.imgur.com/DBjHygm.jpg
Is it normal?

[adrientetar]

iirc Illustrator uses font bounding box as the frame vertical extents, so I guess Noto Sans CJK includes some very tall glyphs.

[kenlunde]

Indeed. The glyphs for U+3031 and U+3032, along with the vertical versions of U+2E3A (two-em dash) and U+2E3B (three-em dash), are tall, and cause the FontBBox to be excessively large. Of course, FontBBox values should not be used for determining line spacing. The appropriate values in the 'OS/2' or 'hhea' tables should be used instead.

[dragonzkiller]

This is more than just an issue for Adobe Illustrator. The FontBBox "issue" is apparently in a lot of major software. I can confirm that this is present in Microsoft Word, Adobe Photoshop and even in Google's own Android. When the Noto Sans CJK-JP Font is replaced with the newest version in Android (purely for experimental purposes) the entire OS goes crazy with it's line spacings (obviously when set to Japanese). This "issue" is not present in WebKit as it works fine in Chrome on PC and Android, but looking through Android's source it looks like it uses the BBox values (WebKit's source seems to use the "correct" values).

I understand why the FontBBox values are very large, but if anything from version 1.004 (or whichever version changed the values) or higher is to be used as a font in anything useful, a lot of large corporations are going to have to update their software to work with it. If I had the time I would be able to write and submit a "fix" for Android, but I obviously couldn't get anywhere with Adobe or Microsoft. Luckily their software allows line spacing overrides, but that's bandaging a wound at best.

I'd like to know what other people think about this as well and what should be done.

[kenlunde]

What I particularly like about Noto Sans CJK and the Adobe-branded Source Han Sans, along with commercial fonts like our (Adobe's) Kazuraki (かづらき), is that they expose bad assumptions or defects in particular implementations. For the Adobe apps, we have bugs open for getting them fixed for this issue, and continue the pressure on the development teams.

The only thing that I can state about MS Word and other MS Office apps is that they generally serves as excellent examples of how not to implement a particular feature or function. They seem to be hard-wired to work well only with fonts that are bundled with Windows OS. In fact, that is the only thing that Microsoft guarantees.

[dragonzkiller]

Thanks for the response.

What I particularly like about Noto Sans CJK and the Adobe-branded Source Han Sans [...] is that they expose bad assumptions or defects in particular implementations.

This exactly. Admittedly the font BBox values are way easier to use: the font is "this big" so make everything that size. But unfortunately easy doesn't always mean best. It's fine enough for European languages with the "same" alphabet, but this is way beyond that. The Adobe and Microsoft issues will take a long time to fix and get out into the world as there's probably multiple places where they read the font metrics. Android doesn't seem too bad though as it looks like one particular library is causing it, and like I said I might play around with it and see what happens. Then again, one small change could mess something else up down the line. We'll see.

[roozbehp]

@dragonzkiller would you please file an Android bug for the issue you are seeing on Android? Here is the instructions: https://source.android.com/source/report-bugs.html

[jungshik]

When the Noto Sans CJK-JP Font is replaced with the newest version in Android (purely for
experimental purposes) the entire OS goes crazy with it's line spacings (obviously when set to
Japanese).

@dragonzkiller, I wonder what you exactly did. Android N already has 1.004. Perhaps, you put Noto Sans CJK JP at the top of the font list (replacing Roboto as the primary font). As far as I know, what you described would only happen if Noto Sans CJK JP replaces Roboto as the primary (UI) font. The same thing would happen if Roboto's yMin/yMax were changed in head table because Android uses yMin/yMax instead of other metrics in OS/2 or hhea AFAIK.

[hrhatada]

I'd like to close this issue since the original question was answered. @dragonzkiller, please read jungshik's comment above and file an Android issue if need.