Preparing Science Gothic for publication on Google Fonts

[yanone]

Let’s use this issue to track specific issues that need to be addressed for onboarding Science Gothic to Google Fonts.

Thomas asked about the general repository structure:
It looks good and is only missing an article/ARTICLE.en_us.html file as per the GF Guide.

As for file formats, we’ll have to stick with UFOs for now. So after every stage of work on the VFC source, please export an up-to-date UFO.

On my computer I exported a new UFO from FontLab 8 using the "Designspace+UFO" profile, but couldn't generate a font from the resulting UFO, as I encountered compatibility issues in composites:

INFO:fontmake.font_project:Loading 36 DesignSpace source UFOs
ERROR:fontmake.compatibility:
Fonts had differing base glyph in glyph uni022A, component 1:
 * 27 fonts had: dieresiscomb.case
 * 9 fonts had: dieresiscomb

ERROR:fontmake.compatibility:
Fonts had differing base glyph in glyph uni0324.case, component 0:
 * 10 fonts had: dieresiscomb
 * 26 fonts had: dieresiscomb.case

fontmake: Error: In 'UFO/ScienceGothic[YOPQ,slnt,wdth,wght].designspace': Compatibility check failed

I checked the glyphs in Fontlab but couldn't find any such inconsistencies. I have little experience with Fontlab, but it appears as though the issue is introduced upon UFO export.

Please see if you can generate a working UFO, and when you do, please name it with the axes in the correct order: ScienceGothic[YOPQ,slnt,wdth,wght].designspace

[kateliev]

Let’s use this issue to track specific issues that need to be addressed for onboarding Science Gothic to Google Fonts.

@yanone great! Thank you!

Thomas asked about the general repository structure: It looks good and is only missing an article/ARTICLE.en_us.html file as per the GF Guide.

I presume @tphinney will take care of that :)

As for file formats, we’ll have to stick with UFOs for now. So after every stage of work on the VFC source, please export an up-to-date UFO.

Ok got it. Will start from the coming week - still doing some changes on the VFC itself dealing with past issue.

On my computer I exported a new UFO from FontLab 8 using the "Designspace+UFO" profile, but couldn't generate a font from the resulting UFO, as I encountered compatibility issues in composites:

This is mostly our fault:

1. We adopted adding our customized FL8 export profile to the projects we work on. But on this one we seem to have not included the profile. Not that it differs that much from the default one, but still... it ensures flawless export.
2. We had a SG-QA test script suite that we used to check for potential problems with the source itself as described in our build docs. But by looking at the docs they seem pretty outdated now, plus the fact that the scripts were never migrated to Python 3.10+ that FL8 uses now. Will take care of that (one way or another).
3. I presume there is some possible glitch with FL's auto layers/auto glyphs and UFO export. We usually remove all the auto stuff and decompose the font before UFO export. Explained in the above mentioned docs

Please see if you can generate a working UFO, and when you do, please name it with the axes in the correct order: ScienceGothic[YOPQ,slnt,wdth,wght].designspace

Noted! Will do!

[kateliev]

Ok I stand corrected. I guess it has been a while... Actually we have all the tools in tact and working :)

All the SG related scripts could be found here.
They require TypeRig to be installed beforehand.

Preparing the font for export is pretty straightforward process that could be explained with the below image. Just run the tool called SG Preflight and follow the steps. Please do not forget to run Font> Update Glyphs in FL beforehand, so that FL updates all the necessary glyph info.

I will attempt export + build tomorrow and report back if there are any issues.

[tphinney]

Thomas asked about the general repository structure: It looks good and is only missing an article/ARTICLE.en_us.html file as per the GF Guide.

I presume @tphinney will take care of that :)

Yes, that is definitely a task for me! I missed it somehow. We have some of the needed pieces, and others are at least in planning (the illustrative graphics). I can do it over the next few days, up to a week at most.

[kateliev]

@yanone just pushed the updated UFO source + variable TTF + fixed VFC source. Will continue on issues in the coming week. Let me know if you need anything, will gladly respond ASAP :)

[kenmcd]

1. We adopted adding our customized FL8 export profile to the projects we work on. But on this one we seem to have not included the profile. Not that it differs that much from the default one, but still... it ensures flawless export.

Would it be possible to get that customized FL8 export profile?
The custom export profile can be saved to a file.

I have been closely following this project to learn how to reliably go from FL8 VFC to UFO and then into the GF build process.
And that custom export profile is one piece I cannot see.
Thank you.

[kateliev]

@kenmcd this is totally my fault :) Just pushed the profile i use at lib/profiles/SG-Build.fl_profile.

[yanone]

@kateliev It builds beautifully now, thank you. Here's a list of issues I found:

• STAT: We need the widths to become part of the STAT table. Is there a way that FontLab can write it to the .designspace file?
• STAT: Only Default is allowed for slnt. Oblique could be different for each font, which is why we don't define it as a fallback.
• STAT: Axis Value for 'YOPQ':'Normal' is expected to be '116.0' but this font has 'Normal'='122.0'. (I have no experience with the parametric axes, but that's what the check and our axisregistry says.)

All the STAT issues are dependent on the question of whether the STAT table can be written automatically. Otherwise we can write one manually in config.yaml which we need anyway and I will PR back to you later.

Furthermore:

• Adjust OFL.txt copyright line to Copyright 2022 The Familyname Project Authors (git url) format (fill in details).
• Remove visit https:, from the article file and add a full stop at the end of that line before </p>

[kateliev]

@yanone thank you!

All the STAT issues are dependent on the question of whether the STAT table can be written automatically. Otherwise we can write one manually in config.yaml which we need anyway and I will PR back to you later.

Unfortunately i do not see out of the box solution for FL. It just does not add the necessary info to the output .designspace file. We use post build statmake in our build script where the stylespace used is lib/ScienceGothic[YOPQ,slnt,wdth,wght].stylespace. So if there is another solution I will gladly take it.

STAT: Axis Value for 'YOPQ':'Normal' is expected to be '116.0' but this font has 'Normal'='122.0'.

About that we are currently discussing it in #319. Probably we will just "fake" the desired default value. Will let you know when we are done with it.

[yanone]

From which folder level do you run your build script? As in, could you please note the command down here? I'm trying to rebuild using your commands. Thank you.

[kateliev]

I usually run from (OS/shell) specified script folder.

Here are the build commands for:

PoweShell (my preferred, as I work mostly on Windows)
sg-build.ps1 -designspace path_to_desigspace_file

Bash
sg-build.sh -d path_to_desigspace_file

Optional keys for both

PowerShell	Bash	Description
-designspace	-d	Path to designspace file
-nopost	-p	Skip postprocessing: statmake and etc.
-notest	-t	Skip Fontbakery testing

Fee free to bug me if something is not working as expected. As mentioned above i use the PowerShell script and i am 100 percent guaranteeing that it works... not so sure about the Bash one :)

[tphinney]

I have more recently switched to zshell as my default shell on Mac.
@yanone what do you use?

[yanone]

@tphinney Also zshell, but not by decision. It’s the default shell on my mac and I can’t tell the difference...

[kateliev]

STAT: Axis Value for 'YOPQ':'Normal' is expected to be '116.0' but this font has 'Normal'='122.0'.

@yanone for now i am "fake" solving this. For further info see my comment in #319. Hope @tphinney is OK with my decision.

[tphinney]

After significant discussion, we are going to actually CHANGE the axis away from YOPQ to… something else. @yanone you were going to point us at an issue for the Axis Registry, because there is another font currently in prep that is doing something similar. Was it this? (googlefonts/axisregistry#42)

[yanone]

No, #42 seems to be limited to a contrast "style" (e.g. translation or expansion), while googlefonts/axisregistry#3 is more general and just describes contrast amount regardless of which contrast axis (angle) is used, as that also depends on the script itself (e.g. Arabic having an inverted contrast axis to Latin).