8000 [varLib] Clarification regarding avar segment maps · Issue #1011 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[varLib] Clarification regarding avar segment maps #1011

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.

Sign up for GitHub

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

Jump to bottom
Closed
jenskutilek opened this issue Jul 21, 2017 · 5 comments
Closed

[varLib] Clarification regarding avar segment maps #1011

jenskutilek opened this issue Jul 21, 2017 · 5 comments
Labels
question

Comments

@jenskutilek
Copy link
Collaborator
jenskutilek commented Jul 21, 2017 •
edited
Loading

The avar spec says:

Axis value maps can be provided for any axis, but are required only if the normalization mapping for an axis is being modified. If the segment map for a given axis has any value maps, then it must include at least three value maps: -1 to -1, 0 to 0, and 1 to 1. These value mappings are essential to the design of the variation mechanisms and are required even if no additional maps are specified for a given axis.

  1. Currently, varLib._add_fvar_avar doesn’t enforce this. Should it?

  2. When an axis doesn’t cover the full range from -1 to 1, it makes no sense to include the entries as described.

For example, take a wdth axis from Condensed to Normal. The mappings may be:

-1.0 to -1.0
-0.5 to -0.3
 0.0 to  0.0

What would an additional 1 to 1 mapping, as required by the spec, do? There is no master at 1.0 for this axis. If something has to be added to the segment map, it should be 1.0 to 0.0, making the range from 0 to 1 effectively flat. If that is the intent of the spec, the wording should be changed.
@jenskutilek jenskutilek mentioned this issue Jul 21, 2017
Closed
@PeterConstable
Copy link

Yes, varLib should enforce this to ensure fonts are valid. This is an old requirement, originating in GX:

"A segment must always have at least three correspondence pairs: minus one mapping to minus one, zero mapping to zero, and one mapping to one."

Your example considers a width axis from Condensed to Normal, but those values are defined only in "user" space, not normalized space. The 'avar' table is a transformation entirely within normalized space which is always defined as having axes going from -1 to +1. An 'fvar' table may happen to define an axis in which default and min or default and max are the same, in which case nothing changes between -1 and 0, or between 0 and +1. But that is a consideration in the mapping from "user" space to normalized space that is independent of the 'avar' transformation that happens entirely within normalized space.

@jenskutilek
Copy link
Collaborator Author

I see ... in that case the normalization done in varLib may be buggy. If I understand it correctly, for my example the normalization should look like this:

User space   Design space    Normalized
 50       ->  50             -1.0 -> -1.0
 75       ->  85             -0.5 ->  0.4
100       -> 100              0.0 ->  1.0 (default)
100       -> 100              1.0 ->  1.0

Is that correct?

@PeterConstable
Copy link

Basically, yes. The one comment is that, since the user range max is the same as the default, then selectable instances can never land in normalized space in the range (0, +1].

So your earlier question, "What would an additional 1 to 1 mapping do?" is valid: it will not have any effect in cases like this. But it has trivial impact and is a small thing for font tools to do.

@behdad
Copy link
Member
behdad commented Jul 21, 2017

I'll follow up on the OpenType list thread. I like to suggest we only require 0->0 mapping. The others are not needed really.

@jenskutilek
Copy link
Collaborator Author

Thanks all. #1014 fixes the issue about the default mappings. The rest was a misinterpretation on my part.

@behdad behdad closed this as completed Jul 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@behdad @jenskutilek @PeterConstable
0