xotypeco / big_shoulders

SIL Open Font License 1.1
69 stars 3 forks source link

Scalable font production #12

Closed vv-monsalve closed 4 years ago

vv-monsalve commented 4 years ago

Build.sh The current build.sh on the repository didn't work to generate the fonts. The file seems to be outdated and doesn't include Inline and Stencil Subfamilies. Thus, this and the patch.ttx file will need to be reviewed and eventually updated to ensure the builds to be repeatable.

Inconsistencies found between current static fonts, fonts on the API, and the source.

While the UPM of the .ttf files on the static folder of the repository is 2000, the source file is 1000UPM, and it's not entirely clear why the difference between them. When generating new static fonts from the current source file using fontmake, they are at 1000 UPM which does match the fonts on the API.

After running new FB checks (only on Text variant), new Fails and Warns were reported. Some of them are related to the Vertical metrics issue, others about the usWeightClass. These Fails are not reported on the current static fonts because somehow they seem to have these values already solved. Nevertheless, they are not in the source file, so the build is not repeatable now.

--

Differences on data between current static .ttf fonts, and the newly generated ones from source file (Text variant) Please note that Diffenator compares and calculates the values despite the difference in UPM, which is still declared there.

Screen Shot 2020-05-14 at 13 29 28

New Fontbakery Report of the last check done to the newly produced statics fonts

davelab6 commented 4 years ago

That new WeightClass value looks like maybe the avar table hasn't been set up, as it was before.

The v metrics ought to be the same across the 6 static families.

The StrikeoutSize is halved because the UPM is halved.

The UPM of the inline is 4000 because there's so much detail. It should be OK to have different UPMs across the set of siblings.

xotypeco commented 4 years ago

will dig into most of this tomorrow, but a note: highest and lowest values of Inline will be higher and lower that other fonts; diacritics are a bit larger and spaced a bit further as necessary to support the optical illusion of staccato between stroke and negative space of the design, which doesn't happen in Big Shoulders and big Shoulders Stencil.

davelab6 commented 4 years ago

Right, but if you have a paragraph that is mostly the normal family but then has a few words in the Inline, you want the line spacing to be uniform in the paragraph, right?

If the v metrics are different, then the line with the Inline text will be taller, by default.

xotypeco commented 4 years ago

Right, but if you have a paragraph that is mostly the normal family but then has a few words in the Inline, you want the line spacing to be uniform in the paragraph, right?

oic. you're right. In that case I should use metrics from inline to govern everything else, but adjusted to a 2000 UPM since it's largest at 4000UPM. thanks for clarification.

vv-monsalve commented 4 years ago

I think that the fundamental idea of this Issue is to ensure font production. Thus, any adjustment made needs to be present on the production files so that they could be replicated.

At the moment, the main concern here is the VM information between the source file and the font files on the static folder do not match, and therefore the build is not repeatable.

xotypeco commented 4 years ago

I can answer this discrepancy you're seeing. VFs and statics are actually generated from production files, where {300,10} and {300,72} are flattened into masters. I didn't include those glyphs files in the repo, assuming they were throwaways (someowhat based on notes @m4rc1e left in the readme).

these glyphs files are aimed at preserving the design, but obvs are causing issue with scalable font output.

so to that end, which is the better move: replacing these glyphs files with actual production files, or adding the production files, noted as such? there's manual work necessary to get from design to production, so I'm not sure what's most helpful in representing that.

(sorry for confusion. @m4rc1e and @yanone did this part of the process for the first generation. this is my first time at this rodeo.)

vv-monsalve commented 4 years ago

Ok, I see. That's on my side, then. I read that at one point but guess I have forgotten about it when attempting to replicate the production, I apologize for that.

Nevertheless, reading it again Marc says

Once fontmake version 2.0 is stable and out, which can deal with brace layers, the use of Big Shoulders Flat.glyphs can be discarded.

I wonder if that is already included in the latest 2.1 version. If so, in that case, what could be done would be to update the fontmake version, so this step with provisional source files wouldn't be needed.

@m4rc1e Would it be the case?

xotypeco commented 4 years ago

@vv-monsalve I just changed source repo. the glyphs files you were working with are now in a design_source directory, and production files are in production_source, so you can see what I actually generated from.

patch.ttx is also there but I didn't use it in my builds. also, similarly have not updated build.sh to accommodate Inline and Stencil (per another question you had). I may have been doing manual work that is incorporated into these files, so this situation could get smoothed over once I figure out what I'm doing :)

vv-monsalve commented 4 years ago

patch.ttx is also there but I didn't use it in my builds. also, similarly have not updated build.sh

So I'm curious now, in that case, how did you generate the fonts? Did you use fontmake or exported them directly from Glyphs app?

xotypeco commented 4 years ago

here's my process, from my notes.

beginning from design files:

increase UPM from 1000 to 2000 in Big Shoulders and Big Shoulders Stencil to override some kinking that happened in instances at 1000UPM

increase UPM from 1000 to 4000 in Big Shoulders Stencil, and finish adjusting points in masters to grid where they've fallen out

(almost entirely in the asterisk character)

1) generate missing braces in all chars

2) expand intermediate braces into masters at {300, 10} and {300, 72}

3) add instance weightClass params

then adjust naming for variables vs. statics, and make the two sets of production files you see in production_source

for variables:

fontmake -g (vf source file) -o variable

then run gftools fix-nonhinting

then run gftools fix-dsig –autofix

for statics:

fontmake -g (static source file) -a -I -o ttf

then run gftools fix-dsig --autofix

then run gftools fix-hinting

xotypeco commented 4 years ago

quick addition here: the issue that you spotted with different vertical font metrics between Big Shoulders/Stencil/Inline isn't addressed in these files, that's on my list to do per this comment from @davelab6

I'm waiting to see if you have comment on the production glyphs files before I do so. fyi!

xotypeco commented 4 years ago

vivi, checking in to make sure the process described above makes sense to you.

I have a running list of private notes from yours and @davelab6's other fixes to incorporate. what is best process? I feel like I should incorporate fixes and then revisit this with more accurate files for generation to test for scalable generation.

vv-monsalve commented 4 years ago

Hi Patric, yes, please prioritize the main design adjustments for now. It would be necessary to test Vietnamese texts, preferably on both Office and design applications, and see if any clipping occurs with the current Vertical Metric values.

Once the source files are ready, I'll work on the build.sh file so many of the steps you perform now manually would be included on it to automate the process and ensure its repeatable in the most practical way possible. I would test if the current fontmake version can elude the external scripts steps (which would be ideal) and we'll continue from there.

xotypeco commented 4 years ago

gorgeous, thank you. for the purposes automation, and also picking a good named VF origin per @davelab6's thoughts, I feel like the flattening of brace layers should be integrated into the design files, rather than being done on production files. I want to move as many processes as possible into those design files so that hopefully the production file step can be eliminated. does that seem sensible, or destructive to you?

vv-monsalve commented 4 years ago

That would be fantastic. I believe it's the best practice actually. So if it's possible yes, please do it :)

xotypeco commented 4 years ago

new source files in the repo now. font files in the fonts folder are from the last generation, I haven't re-generated with new source.

changes:

1) brace layers flattened to master (Text regular and Display Regular)

2) vertical metrics fixed per your recommendation Inline winAscent = 5228 winDescent = 1460 Stencil and Big Shoulders winAscent = 2614 winDescent = 730 (since they are half the size)

3) carets set on ligature characters

4) variable font origin set to Text Regular for all fonts

5) interpolated Regular masters renamed to "Text Regular" and "Display Regular" for clarity

6) diacritics with ogoneks repaired

7) Ldot repaired (dot had gotten moved in Stencil)

8) added .notdef design (it's boring)

this should go quite a ways to make this process more scalable.

to edit the process I was following before, you should now be able to do this:

fontmake -g -o variable

then run gftools fix-nonhinting

then run gftools fix-dsig –autofix

for statics:

fontmake -g -a -I -o ttf

then run gftools fix-dsig --autofix

then run gftools fix-hinting

vv-monsalve commented 4 years ago

New source files plus the new build.sh are allowing now a more repeatable and scalable production, in a simpler way also. Thanks for flattening the layers!

xotypeco commented 4 years ago

yup, no problem. doing so let me define the origin as Text Regular, since it's now a master. I'd been wanting to do that anyway.