8000 [VARC] Special-case hidden axes when applying RESET_UNSPECIFIED_AXES to pen.addVarComponent() by justvanrossum · Pull Request #3549 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[VARC] Special-case hidden axes when applying RESET_UNSPECIFIED_AXES to pen.addVarComponent() #3549

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

justvanrossum
Copy link
Collaborator

Alternative to #3541.

As explained in #3541 (review), the rawLocation mechanism is needed to meaningfully extract variable components via addVarComponent().

But this gives a bit of a conundrum with the new meaning of RESET_UNSPECIFIED_AXES.

Old meaning: when RESET_UNSPECIFIED_AXES is set, reset unspecified axes to default
New meaning: when RESET_UNSPECIFIED_AXES is set, reset unspecified axes the current font location

  • to extract variable components for a glyph, we instantiate the glyph at all locations for which the glyph has variations
  • this means we also need to specify values for the "private" axes used for variable components
  • but these values should not "leak" into descendants
  • for normal rendering this is no problem, as the private axes are not user-settable (they are hidden), so the "global font location" for these axes is at default anyway

Long story short, to implement RESET_UNSPECIFIED_AXES in a useful way for addVarComponent(), we need to special case hidden axes.

@justvanrossum justvanrossum requested a review from behdad May 30, 2024 18:04
@behdad
Copy link
Member
behdad commented May 30, 2024

we need to special case hidden axes.

I'm a bit uncomfortable with that. Can we change the protocol and send two locations down?

@justvanrossum
Copy link
Collaborator Author

I'm a bit uncomfortable with that. Can we change the protocol and send two locations down?

Hm, then we burden the addVarComponent signature with this problem. Not sure which is better.

The way we currently compile with RESET_UNSPECIFIED_AXES already depends on those axes always being at the default: as soon as you set one to a non-default value, the font breaks, as can be seen in (my private build of) FontGoggles:

Screen.Recording.2024-05-30.at.20.50.34.mov

So those axes are already special, and to me special-casing them here doesn't make things worse.

@justvanrossum
Copy link
Collaborator Author

Potentially we could amend the spec to say that RESET_UNSPECIFIED_AXES should reset to the current location for non-hidden axes, and to default for hidden axes?

@behdad
Copy link
Member
behdad commented May 30, 2024

Hm, then we burden the addVarComponent signature with this problem. Not sure which is better.

What if we add a lower-level addVARCComponent or something that takes exactly what's in the format? The location as well as the flag?

Let me also think more. In my compiler I drop encoding axes if they have the same value as the parent glyph. Let me think more about your requirements and get back to you.

@justvanrossum
Copy link
Collaborator Author

I'm having a hard time to come up with a use case for pen.addVarComponent() that is other than mine... There is of course the option that I don't use the pen protocol for this at all, and just read VARC directly. Maybe that makes more sense.

There's also your earlier idea if having two flags:

  1. reset to font location
  2. reset to default

The first is handy when we pass down (user) axes to deeply nested components. The second is what we really need for private axes.

@justvanrossum
Copy link
Collaborator Author

(Hm, additionally, pen.addVarComponent() doesn't support extracting conditions (which Fontra doesn't yet support), but that also suggests that the pen protocol is perhaps not the right tool to extract variable components.)

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.

2 participants
0