Another round of font updates

[NiLuJe]

Noto & FreeFont ;).

[NiLuJe]

There was mention of kerning tweaks with accented characters, so our weird bugs w/ FT kerning with the original rebuild might suddenly make more sense ;).

Otherwise, it's fairly minor, some misplaced glyphs put in the right place.

Noto is... murkier. I'm going to go with: not much ;).

[poire-z]

Spent some time suspecting a bug in HB drawing code, as on my Kobo I got this (bad):

while on the emulator I got this (good):

Turned out I had an alternative NotoSansCJKsc-Regular_latest.otf (I had downloaded some months ago) on the emulator - if I remove it so it uses the one we ship (from this PR I think), I get the same bad result as on my Kobo.

But the CJK fonts that can be downloaded currently at https://www.google.com/get/noto/help/cjk/ are all dated 2015-06-15, so they are not that recent - and we should be shipping those.

16412332 Jun 15 2015 NotoSansCJKsc-Regular_latest.otf (the one I just downloaded) 17281332 Aug 14 2019 NotoSansCJKsc-Regular.otf (the one we ship)

@NiLuJe : did you do some massage to this font before adding it (like removing hinting or something?)

[NiLuJe]

@poire-z: Nope, it's straight from the repo.

I'm guessing Google doesn't actually ship > 2.0, for some reason, then? (c.f., https://github.com/googlefonts/noto-cjk/commits/master/NotoSansCJKsc-Regular.otf).

[poire-z]

Forgot to say that this happens when setting typography language to Japanese (the font then switches some glyphs). No issue with that same font when setting it to Chinese.

Tried with NotoSansCJKjp-Regular.otf downloaded from that github repo: no issue whether set to Japanese or Chinese. So, possibly some bug in that NotoSansCJKsc-Regular.otf in that repo...

[NiLuJe]

If we handle font collections properly, switching to the 'Regular' OpenType/CFF Collection (OTC) might help?

c.f., https://www.google.com/get/noto/help/cjk/

[poire-z]

I don't know if crengine (or freetype) supports them. crengine enumerates stuff in the file we provide, may be that's enough ?

        // for all faces in file
        for ( ;; index++ ) {
            int error = FT_New_Face( _library, fname.c_str(), index, &face ); /* create face object */

But about what we currently ship:

Language-specific OpenType/CFF (OTF)

Each font sets one language as the default. Note that each language-specific font does support all four languages and includes the complete set of glyphs. However, you need an application program that can invoke an OpenType locl GSUB feature (e.g. Adobe InDesign) to access language-specific variants other than the default language.

So, now that we have that Typography menu where we can choose Chinese, Japanese, Korean, we have that (but ok, only in "best" kerning mode - which should be fine enough).

[NiLuJe]

Yep, my naive understanding of font collections tells me that should be enough to support it (no idea about xtext, though).

You can test that theory with the v2.001 TTC: https://github.com/googlefonts/noto-cjk/blob/master/NotoSansCJK-Regular.ttc

[poire-z]

Well, removing all NotoSansCJK* and just dropping that NotoSansCJK-Regular.ttc is enough to make appear in our font menu: So, TTC work :)

Typography>japanese (or korean), and selecting HK, SC or TC make that middle dot bug. Selecting JP or KR does not. Typography>chinese (simplified or traditional), and selecting any of HK, SC, TC, JP, KR: no bug.

So, that 2.001 is a bit inconsistent or buggy :)

But I'd rather not have that TTC and my font menu filled with 4 more fonts I will never use :) xtext will tell harfbuzz to pick the glyphs and features from the UI language (or wikipedia language) - so no need for TTC on the UI side.

[poire-z]

In frontend/fontlist.lua, we have:

                if file_type == "ttf" or file_type == "ttc"
                    or file_type == "cff" or file_type == "otf" then

[NiLuJe]

Feel free to downgrade to the 1.004 SC TTF then, or I'll do it the next time I update the fonts ;).

[poire-z]

I'd rather let you do it :) (no hurry, my japanese reading can wait :)