-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add '--expand-features-to-instances' arg to fontmake UFO generation #985
base: main
Are you sure you want to change the base?
Add '--expand-features-to-instances' arg to fontmake UFO generation #985
Conversation
Oh, I’ve also just realized that the current config option for this seems to activately prevent a build from working. After I tested the above solution on a config that included [229/1410] buildTTF
FAILED: /var/folders/nb/mc9zt2n930vd_jkbg0kn2d680000gn/T/tmp8ertvdij
/Users/stephennixon/venv/bin/python -m gftools.builder.jobrunner fontmake --output-path /var/folders/nb/mc9zt2n930vd_jkbg0kn2d680000gn/T/tmp8ertvdij -o ttf -u sources/ufo/instance_ufos/FamilynameExtraCompressed-Hairline.ufo.json --filter ... --filter FlattenComponentsFilter --filter DecomposeTransformedComponentsFilter --expand-features-to-instances
Command failed:
fontmake --output-path /var/folders/nb/mc9zt2n930vd_jkbg0kn2d680000gn/T/tmp8ertvdij -o ttf -u sources/ufo/instance_ufos/FamilynameExtraCompressed-Hairline.ufo.json --filter ... --filter FlattenComponentsFilter --filter DecomposeTransformedComponentsFilter --expand-features-to-instances
usage: fontmake [-h] [--version] [-g GLYPHS | -u UFO [UFO ...] | -m
DESIGNSPACE] [--glyph-data GLYPHDATA] [-o FORMAT [FORMAT ...]]
# etc etc etc
fontmake: error: "--expand-features-to-instances" option invalid for UFO source With that arg removed from the static font step, the build does complete.
Okay! I’ve figured out how to access and pass that config option to the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arrowtype Please fix the lint issues and I'll take another look.
… blocks the build
…step; make True by default
a429d71
to
cc8617e
Compare
Thanks, @m4rc1e! I believe it’s now formatted as desired. It seems to need approval to run the workflow to verify that, though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no way of enabling and disabling this flag inside a config file, You need to add expandFeaturesToInstances
to the builder's argument schema, https://github.com/googlefonts/gftools/blob/main/Lib/gftools/builder/schema.py#L66.
It is enabled by default in this pr. I'd prefer it if it was set to false and then the user has to enable it in their config files.
Okay, thanks for taking a look and for suggesting that update! Fair enough. I’ll try to make those adjustments soon. |
@m4rc1e Oh wait, isn’t it already there in the schema? It’s also described in the docs. This PR merely makes it work as already described. gftools/Lib/gftools/builder/schema.py Lines 102 to 104 in d23ad21
gftools/docs/gftools-builder/README.md Lines 170 to 172 in d23ad21
|
In the past, @anthrotype has suggested that this option should be the default:
The builder seems like a place it might make sense to do that, and that’s why I figured it was documented as such. Or, do you think it’s important to keep it non-default? I don’t think it would be a breaking chance to make it default, as I don’t think it blocks features that are already flattened into each source. |
@@ -59,6 +59,8 @@ def targets(self): | |||
def variables(self): | |||
vars = super().variables | |||
vars["args"] += " --ufo-structure=json " | |||
if self.original["expandFeaturesToInstances"]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason why you're using self.original
here? It is breaking the tests since expandFeaturesToInstances
isn't in self.original
. If I change it to vars
it seems to be working but I could be wrong.
Personally, I would use a dict's get
method if I cannot guarantee that a key exists. It also allows you to set a value incase it doesn't exist so in your case self.original.get("expandFeaturesToInstances", False)
will return False if the key doesn't exist, or it will simply return the value if it does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, thank you for that tip on .get()
– that is news to me, but really helpful to learn!
Any reason why you're using self.original here?
As far as I can remember, I think I just tried to use a similar format as what is a few lines below:
if self.original.get("glyphData") is not None: |
...and when it seemed to work, I thought I had solved it.
My impression was that self.original
is the GOOGLEFONTS_SCHEMA
, but I now realize that, even if that is true, there are other possible schemas.
if self.config.get("expandFeaturesToInstances"): | ||
args += " --expand-features-to-instances" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we 100% sure that this doesn't work? If I was implementing such a feature then I'd simply chuck it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the approach in the release as of when I made the PR, right? If so, then yes, I’m 100% sure it wasn’t working. I can test it again, though, if it seems likely that it may have changed since then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That line feels right - I think I'd like to understand why it's not working before trying something else, because understanding why not might lead us to the right answer.
UFOs can use relative
include
statements to import feature files, which is very helpful in the case of a family that has many UFO sources, but just one feature file required. Or, it’s helpful if there are many features, and several complex ones, so they are split into multiple files (example: a Recursive UFO source and its features directory).Currently, the Builder just brings the
include
statement directly into the instance UFOs, but then the relative paths are broken, so the fonts don’t build.However, it is very easy to support by adding the arg
--expand-features-to-instances
to the UFO instantiation step, as I have done in this PR.I’ve tested this on a UFO-based family (with
include
s) and a Glyphs-based family (with normal Glyphs-based features), and it seems to work well in both cases. The features are built into the fonts, as expected.I’m not aware of any downsides or hidden issues with adding this, but they might exist. If any are known, I would be very interested in learning about such cases.
Please let me know if you have any questions or suggestions here! Thanks so much.