[buildmasterotfs/buildcff2vf] only works for UFOs without processed layer

[frankrolf]

Currently, our CFF2 VF building workflow is split in two steps – buildmasterotfs (to build dummy OTF files from UFO masters), and buildcff2vf (to merge these OTFs into a Variable CFF2).

I think it is problematic is that buildmasterotfs quietly requires master UFOs without a glyphs.com.adobe.type.processedglyphs layer – otherwise the VF merging in step 2 will fail because of outline incompatibilities.

I wonder if there could be a way to make buildmasterotfs independent of the processed layer. Since buildmasterotfs just wraps makeotf, this would require adding an “prefer foreground layer” option there.

[frankrolf]

An additional thought I just had about this – any hinting information is present in the processed layer. How would that info make it into a variable CFF2 in a potential future workflow?

[miguelsousa]

How would that info make it into a variable CFF2 in a potential future workflow?

The UFO masters would have to have that data in the foreground layer as well. By default the hinting data is added to the processed layer, but psautohint has an option for not doing that.

[frankrolf]

Would there be a way to force makeotf to build from the foreground layer?
I just spent way too much time on tracking down a build error, just to find out that one of my UFOs contained a processed layer, while others didn’t.

[frankrolf]

This fell on my feet once again. If there was a way to make makeotf ignore the processed layer, that would solve the problem (because it could be implemented in the buildmasterotfs script).

[frankrolf]

Encountered today by @ibo-o – as far as I can tell, it was a waste of time to figure out the problem.

[skef]

Looking at this I'm wondering what the specific problem is.

If buildmasterotfs works differently depending on whether there is a processedlayer or not, that suggests that it uses the processedlayer for the glyph sources if it's present. So buildcff2vf should work as long as the "processed" (i.e., hinted) sources are compatible. And I think that's what was intended -- you want to provide the option to pre-hint the sources as an alternative to post-hinting.

So it seems like the issue here isn't necessarily that buildmasterotfs works the way that it does, but that it's too easy to wind up with processedlayers that weren't hinted "together".

Maybe the right solution for this is to use the layer name glyphs.com.adobe.type.processedglyphs for hints that were generated from a single source, and some other layer name (maybe glyphs.com.adobe.type.mutliprocessedglyphs?) for hints that were generated from multiple sources, and only have buildmasterotfs look at the latter, and maybe warn if the former is present.

[frankrolf]

The problem is that buildmasterotfs just acts like makeotf – if there‘s a processed layer in the source file, it’ll prefer that when building the OTF. The processed layer doesn’t only contain hints, it also contains the results of checkoutlinesufo – in most cases, that’ll make outlines incompatible. (This layer may be a residue from testing the master UFO as a static font).

To make this process more bulletproof, buildmasterotfs should really only build whatever is in the foreground layer. I’m not really keen on adding more files to the UFO file – not sure that’s needed, even.

[skef]

This change would be equivalent to saying that you can't hint the glyphs in a variable font before building it. So we should be sure that's OK and not needed for, e.g., CJK fonts.

[punchcutter]

This change would be equivalent to saying that you can't hint the glyphs in a variable font before building it. So we should be sure that's OK and not needed for, e.g., CJK fonts.

Definitely doesn't matter for our CJK fonts now. We aren't hinting the variable fonts yet and even if we will in the future it will be after the VF build.

[skef]

Maybe we can add a switch that says to use the processed layer but default to the foreground, which should take care of 99% of the problem assuming people don't want to pre-hint their sources.

[frankrolf]

I have a feeling we’re discussing the same problem from two different perspectives. I understand Skef’s concern from a future standpoint – but right now, it’s just too easy to try and merge incompatible sources.

This all calls for the replacement of the 2-step workflow – maybe with a tool which will be able to hint sources on the fly, and merge those hinted VFs – without leaving tons of data in the UFO files.

[skef]

The only benefit of hinting "before" rather than "after" is that you can do it once and then rebuild multiple times. So there isn't much benefit to hinting in the middle versus after the font is built.