Skip to content
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

L4 fixes #3179

Merged
merged 11 commits into from Jul 11, 2023
Merged

L4 fixes #3179

merged 11 commits into from Jul 11, 2023

Conversation

behdad
Copy link
Member

@behdad behdad commented Jun 21, 2023

@behdad
Copy link
Member Author

behdad commented Jun 21, 2023

Err. Needs more work.

@behdad
Copy link
Member Author

behdad commented Jun 21, 2023

This still seems to produce wrong results with avar present. Sigh.

@behdad
Copy link
Member Author

behdad commented Jun 21, 2023

This still seems to produce wrong results with avar present. Sigh.

I think I fixed it.

@behdad behdad force-pushed the L4-fixes branch 2 times, most recently from fbc7541 to 0199946 Compare June 21, 2023 20:50
@behdad
Copy link
Member Author

behdad commented Jun 21, 2023

Tests fixed.

@behdad
Copy link
Member Author

behdad commented Jun 21, 2023

I think this is good now.

outGain is always zero in this branch.
Imagine a font with current min/default/max of 100,700,1000. And new
setting of 100,400,1000. The current normalizeLocation will calculate
the new location for 700 to be +.33, whereas it should calculate +.5!
This is because 400 translates to -.5, so 700 will be normalized to
-1,-.5,+1 and get +.33...

We need a special normalizeLocation that is aware of the "distance"
between min/default/max, ie. the non-normalized values. Then it will be
clear that the distance from 400 to 700 is equal to 700 to 1000, and as
such 700 should be normalized to .5, not .33... I'm still trying to
figure out the case where avar is present.

Store this distance in NormalizeAxisLimit and reach it out in the
solver.

Fixes #3177
@behdad
Copy link
Member Author

behdad commented Jun 22, 2023

With the latest changes the test coverage is complete for the change.

Copy link
Member

@anthrotype anthrotype left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it strange that we didn't catch this before, when L4 was not implemented yet. Can you confirm that nothing basically has/will change after this PR for the pinning-axis and restrict-axis-but-keep-default cases of partial instancing, and that these changes only affect when move-axis-default is involved?

Lib/fontTools/varLib/instancer/__init__.py Outdated Show resolved Hide resolved
Lib/fontTools/varLib/instancer/__init__.py Outdated Show resolved Hide resolved
Lib/fontTools/varLib/instancer/featureVars.py Outdated Show resolved Hide resolved
Lib/fontTools/varLib/instancer/solver.py Outdated Show resolved Hide resolved
Lib/fontTools/varLib/instancer/solver.py Outdated Show resolved Hide resolved
Tests/varLib/instancer/instancer_test.py Outdated Show resolved Hide resolved
Lib/fontTools/varLib/instancer/__init__.py Outdated Show resolved Hide resolved
Tests/varLib/instancer/instancer_test.py Show resolved Hide resolved
Lib/fontTools/varLib/instancer/__init__.py Outdated Show resolved Hide resolved
Lib/fontTools/varLib/instancer/__init__.py Show resolved Hide resolved
if lower >= 0:
return (v - default) / (default - lower)

# lower < 0 and v < default
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that your example make sense but I'm still not 100% clear why this situation in which default >=0 and v < default and lower < 0 needs to take into account the positive/negative distances, whereas the other cases do not. Is it because in this particular case the value v falls in a segment that may span both the negative and positive sides and thus the ratio between these two matters?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it because in this particular case the value v falls in a segment that may span both the negative and positive sides and thus the ratio between these two matters?

Correct.

@behdad
Copy link
Member Author

behdad commented Jul 10, 2023

I find it strange that we didn't catch this before, when L4 was not implemented yet. Can you confirm that nothing basically has/will change after this PR for the pinning-axis and restrict-axis-but-keep-default cases of partial instancing, and that these changes only affect when move-axis-default is involved?

Correct. Because as you noted, this only affects cases where the new default moves, and the new range for min-side or max-side spans over the previous default, which only happens with L4. And yes I'm also surprised we didn't catch this before.

@behdad
Copy link
Member Author

behdad commented Jul 10, 2023

Thanks @anthrotype. I think I addressed all your feedback.

Copy link
Member

@anthrotype anthrotype left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks LGTM! Remember to fix the typo

@behdad behdad merged commit fb56e7b into main Jul 11, 2023
7 of 8 checks passed
@behdad behdad deleted the L4-fixes branch July 11, 2023 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[varLib instancer, L4] Applying a new default location shifts up weight of Bold, etc
2 participants