-
Notifications
You must be signed in to change notification settings - Fork 94
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
CompatibilityChecker
: check all layers within designspace sources
#1090
base: main
Are you sure you want to change the base?
Conversation
Create CompatibilityChecker from designspace, instead of list[Font] Before layer names weren't being honoured when looking at sources Co-authored-by: Harry Dalton <[email protected]>
Co-authored-by: Harry Dalton <[email protected]>
good catch about CompatibilityChecker not actually checking sparse layers
it depends on whether those anchors are going to be used or not by the (variable) markFeatureWriter. I presume they should. Aren't they? |
The question is less about anchors specifically and more about whether everything the compatibility checker was looking at on the default layer is equally applicable (and at the same level of severity) on other layers Based on the fact the code seems to have been written with the author(s) thinking all layers were being checked, I'm inclined to believe the answer to the question is "yes", however we may find this starts throwing errors on fonts that were previously building due to the increase in 'test coverage'. We wanted to be cautious about forcing it on the world as no one likes updating dependencies and then having their build stop working, regardless as to whether that new error is a 'good thing' or not Essentially, @Hoolean & I were just wanting to check what would be the desired behaviour for these now-actually-being-checked layers before we finished adding/updating tests Hope that makes sense! |
I see. In that case, I believe that if an intermediate layer does not have some anchor it should not be an error, perhaps not even a warning; it may be intentional and simply mean, this particular layer doesn't participate in the building of variable mark feature deltas (i.e. the anchor position will be interpolated at run-time for that location). |
So the new things that are being checked in sparse layers:
Other to-dos:
|
@RickyDaMa you should first actually check that it works as intended in ufo2ft and doesn't crash. this remindes me googlefonts/ufo2ft#840 |
what's that? |
These things: fontmake/Lib/fontmake/compatibility.py Lines 49 to 64 in 8f450ef
|
ah it's the glyphsLib's ContextualMarkFeatureWriter well I suppose whatever treatment you apply for anchors in general you should also apply for their GPOS context |
@RickyDaMa actually this works as of now thanks to @khaledhosny googlefonts/ufo2ft#842 |
The problem is that the compatibility checker iterates over every source but does not consider whether they are sparse layers
This means that it duplicates work and misrepresents how many sources it's checking (given that it counts every layer, but only checks the default layer for each UFO)
This PR changes the reporting to be accurate (and improves phrasing / word choice to aid understanding), and extends the
CompatibilityChecker
's scope to include the previously unchecked non-default layersThere's definitely cases where more checking is more betterer, however it'll creating additional compatibility check failures (even in the test data used within this repository). Before continuing this PR with tests etc., we want to make sure that the checks aren't now overstepping from correctness into things that should be warnings (e.g. are mismatching anchors in sparse layers worth failing the build over?). We'll add & update tests once we've discussed & decided
Aside: https://matklad.github.io/2022/10/24/actions-permissions.html