Open cmyr opened 1 week ago
There's precedent for using alternative implementations of an operation: see the (now badly-named) hbsubset
operation which can be switched between hb-subset
and pyftsubset
. But that's a bit easier to handle because the command line arguments are deliberately identical; we can just have a $subsetter
variable in the ninja rule and set it appropriately.
How compatible are fontmake and fontc command lines?
Thinking "aloud" we are eventually going to need gftools in Rust which makes me wonder if we should begin to spin that up.
There's precedent for using alternative implementations of an operation: see the (now badly-named)
hbsubset
operation which can be switched betweenhb-subset
andpyftsubset
. But that's a bit easier to handle because the command line arguments are deliberately identical; we can just have a$subsetter
variable in the ninja rule and set it appropriately.How compatible are fontmake and fontc command lines?
They aren't identical but if I know the fontmake args I can try to rewrite them for fontc?
See notes on above PR.
Opened #1047 to show loosely how I imagine this could work. @simoncozens can you identify any possible problems with that approach?
I would like to start testing using
fontc
in place offontmake
in the gftools builder pipeline, and I'm hoping to discuss how best to do this. Ideally this work would be isolated and non-invasive enough that it could happen in this repo, instead of in a fork.The main requirement for this work would be some way to pass a flag that would opt us into
fontc
mode. I imagine that this would involve adding some new 'Operations' that can be run in place of the currentBuildOTF
andBuildVariable
classes, and which would be backed byfontc
. (An environment variable could be used to pass a path to thefontc
executable.)When the user passed the
--experimental-fontc
(or whatever) flag, we would then use the alternative operations instead of the default ones; I'm not sure how best to plumb this through, but I could imagine possibly modifying theknown_operations
or else adding anoperation_overrides
dict or something like that; I imagine this project's maintainers might have a better sense of how best to do this.Does this make approximate sense? Is there anything else I'm missing?