-
Notifications
You must be signed in to change notification settings - Fork 43
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
trouble running ufo2ft filters (answer: I had a typo... but maybe the docs could improve in this aspect?) #792
Comments
Hey! thanks, I can see that can be confusing. The USAGE.md docs are correct though, when they mention the --filter CLI flag it says:
note the "ClassName" there. The convention in ufo2ft filters is that the classe names all end with "Filter" (the module names containing those classes do not end with "Filters"). Maybe we could be more lenient and if we don't find the given class, attempt to find it with the "Filter" suffix appended.. |
Thanks for the reply! Totally, I get that there is no actual fault or inaccuracy in the docs. I just got confused by not knowing offhand what the exact ufo2ft classnames are. The docs are helpful, but could perhaps be made a little more easy to use if the exact ufo2ft filter class names are listed. But, right, I can see why that might not make sense, too. Largely, I posted this in case someone else trips on that and goes searching for the answer. If making the class matching a little more lenient seems sensible, that could be nice. Do the ufo2ft names include "Filter" when listed in a UFO lib? If not, that may be one reason to make the match a little more lenient. |
you're right that they do not, and in fact the they are under a "name" key, unlike the feature writers which have a key called "class". A filter name != class name. I think this is because filters were implemented to support Glyphs.app's own filters like "Transformations" etc.. Maybe I'll move this issue over to ufo2ft and so someone can fix this. I don't have time right now, sorry. But thanks again |
Okay, thanks again for taking the time to talk that through! |
I’ve realized what I was doing wrong, but I’m leaving the issue in case someone else has the same issue in the future. An explanation is at the bottom of this comment.
My problem
I’m building fonts from a Glyphs source, but having trouble applying ufo2ft filters.
For example, here’s what I’m getting when I try to add
--filter PropagateAnchors
.I’m also having trouble running
--filter DecomposeTransformedComponentsFilter
, even though I am following the format suggested in USAGE.md:I’m building in a venv, with versions:
3.7.1
2.33.4
FontMake seems to be building without issue, otherwise.
Am I missing something?
One additional question
How can I run multiple filters? Would I add it twice, like
--filter DecomposeTransformedComponentsFilter --filter PropagateAnchors
, or once, with a comma-separated list, like--filter DecomposeTransformedComponentsFilter,PropagateAnchors
, or in some other way?UPDATE: I figured it out
I was missing something: it isn’t
--filter PropagateAnchors
, it’s--filter PropagateAnchorsFilter
(with theFilter
on the end).Also, yes, using two filters seems to work well like this:
fontmake -g "familyname.glyphs" -o variable --filter DecomposeTransformedComponentsFilter --filter PropagateAnchorsFilter
Possible improvement to docs?
I was trying to use
--filter PropagateAnchors
because in USAGE.md, the filter is listed as simplyPropagateAnchors
– with code highlighting, suggesting that it is the literal code expected. However, the actual argument required isPropagateAnchorsFilter
, with the repeated word "Filter". Maybe the docs should include this "Filter" with the labels? So, it could be adjusted like this:Or, perhaps even better, maybe these args could be simplified to also work with the simpler arg:
--filter PropagateAnchors
? I’m not sure what it would take to make this work, though, and it may not be worth the added lines of code.Maintainers: feel free to close this if no action seems warranted. I just figured I might suggest possible improvements. Thanks!
The text was updated successfully, but these errors were encountered: