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

Alternative lookup variations mechanism for variable fonts #57

Open
skef opened this issue Sep 11, 2023 · 1 comment
Open

Alternative lookup variations mechanism for variable fonts #57

skef opened this issue Sep 11, 2023 · 1 comment

Comments

@skef
Copy link

skef commented Sep 11, 2023

Discussion in issue #53 lead to the design of alternative, more ambitious design for a replacment (or complement) to the existing feature variations mechanism. This issue is for discussion and potential adoption of that design, or what it evolves into.

With the current system a single list of condition sets is evaluated in order until one set evaluates all true, and then whatever feature indices are listed in that entry replace the original feature table. In this alternative system the basic unit of replacement is not feature tables but lookups, and all elements in the list are evaluated. When all conditions in a set evaluate to true, a set of lookups associated with that condition set is added to the “current” set. Instead of building complete substitute feature tables for regions of designspace, with this alternative one can simply associate individual lookups with their own condition sets and build the overall table by evaluating those condition sets. At the end of the search, the total set of added lookups encountered is used as the list for the corresponding feature.

The document also includes a proposal for negating conditions. Many forms of logical analysis, such as reduction to disjunctive normal form benefit from an easy means of negating a boolean variable, which in the case of feature variations corresponds to a condition. With the current condition format 1, conditions that use only one of filterRangeMinValue or filterRangeMaxValue can be negated by adjusting the F2DOT14 value by the minimum increment, moving it to the other field, and adjusting the original field to -1 or 1. However, there is no general way of negating a condition that uses both filterRangeValues with a single condition. The proposal adds that mechanism.

Proposal document: newfeatvar.pdf

@skef
Copy link
Author

skef commented Sep 11, 2023

@behdad Give this write-up of ideas from #53 when you have a chance. I'm also happy to add you as an author instead of just the initial mention.

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

No branches or pull requests

1 participant