GF preparation

[aaronbell]

Hello! I'm going to start preparing this font to be onboarded to Google Fonts (thank you for your patience—only took 3 years!).

Some questions:

1. In your initial issue submission you mention that the JPS / JPN versions require further testing. Can you give a perspective on the status of those parts of the project? I figure if we're making the effort to do onboarding of the SC/TC families, it might be worth doing the full set.

2. I would like to be able to run the build script on non-Windows systems. I think I can re-implement the build_mergefile.bat as a shell script, if that's alright?

3. Are you open to considering the newer vertical metrics that we discussed or would you prefer to leave your metrics as is?

4. If I find issues in the fonts that need to be addressed, do you want me to post a list here, or attempt to fix them myself and submit a PR? What is your preference?

Thanks!

[NightFurySL2001]

1. I actually saw advertisement for JP version of this font on Twitter and there seem to be not much inquiries on the font so far, so if you think the font has enough coverage for Japanese then I think it can be uploaded for the whole family.
2. Yes, that will be fine. [The build system is quite old though at this point, and depends on binary TTF directly exported from FontLab. I am currently considering to switch to designspace+UFO with a new build script]
3. I think the newer metrics should be fine as long as it can match the original behaviour, since the current metrics came from https://github.com/googlefonts/zcool-qingke-huangyou.
4. I think a list should be ok. Noted BASE is currently missing.

[aaronbell]

I'll check out the Japanese and see how it looks. But figure I might as well onboard it since I'm here! :)

Meanwhile, I got the build process up and running using a shell script versus the bat file, and added some GF-specific bits. It seemed easier to take the existing OTF that are generated out of your build system, convert them to TTFs, and then modify the binaries. So there's no change to your existing build system whatsoever, and this just layers on some modification overtop.

All in all, the changelist seemed pretty small:

• Implemented symmetric smoothing GASP fix
• change name of space / nbspace from CID naming (CID is not applicable in TTFs anyway)
• update name table URLs and copyright strings per FB guidance

And separately, I updated the vertical metrics based on the new CJK guidance and merged in the BASE table.

See what you think.

[NightFurySL2001]

Thank you for the recommendations. For BASE tag i believed that it should be fully defined in this case as this is a rectangular font instead of a square font. I'm thinking of using this BASE table in features.fea:

table BASE {
  HorizAxis.BaseTagList                 icfb  icft  ideo  idtp  romn;
  HorizAxis.BaseScriptList  DFLT  ideo  -104   814  -120   880     0,
                            hani  ideo  -104   814  -120   880     0,
                            kana  ideo  -104   814  -120   880     0,
                            latn  romn  -104   814  -120   880     0,
                            cyrl  romn  -104   814  -120   880     0,
                            grek  romn  -104   814  -120   880     0;

  VertAxis.BaseTagList                  icfb  icft  ideo  idtp  romn;
  VertAxis.BaseScriptList   DFLT  ideo    49   716     0   765     0,
                            hani  ideo    49   716     0   765     0,
                            kana  ideo    49   716     0   765     0,
                            latn  romn    49   716     0   765     0,
                            cyrl  romn    49   716     0   765     0,
                            grek  romn    49   716     0   765     0;
} BASE;

This will match the design values I had used during the design phase (documented in https://github.com/NightFurySL2001/WD-XL-font/blob/main/documentation/TECHNICAL.md). I think the CID names are fine since those are technically problems with otf2ttf, and I can't guarantee the glyphs will still be in the same location after processing. I will integrate the name URL table changes and GASP fix (it's the gftools fix-nonhinting right?).

I just found a problem with the proposed vertical metrics. The new metrics will break the vmtx table of the features.fea parser included in AFDKO makeotf as the default values are pulled from OS/2.Typo values. Changing this will break the vmtx table unless I manually specify all the vertical heights for the glyphs, which is unreasonable to include all 20k+ glyphs just to specify the heights.

[aaronbell]

The more complete BASE table sounds good to account for the design! You can either add it directly into the feature file, or as a post-production step.

I will integrate the name URL table changes and GASP fix (it's the gftools fix-nonhinting right?).

Yup! Sounds good.

I just found a problem with the proposed vertical metrics. The new metrics will break the vmtx table of the features.fea parser included in AFDKO makeotf as the default values are pulled from OS/2.Typo values. Changing this will break the vmtx table unless I manually specify all the vertical heights for the glyphs, which is unreasonable to include all 20k+ glyphs just to specify the heights.

Hmmmm. I think that in this case, the vertical metrics will need to be modified as a post-production step on the binary. Like you said, it is unreasonable to modify everything to account for makeotf's expectations.

[aaronbell]

Btw, closing the loop on the space naming item. It appears that that check was depreciated recently so it’s all good.