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

Adding data for votf/vuid #16

Open
dberlow opened this issue Jan 14, 2024 · 3 comments
Open

Adding data for votf/vuid #16

dberlow opened this issue Jan 14, 2024 · 3 comments
Assignees

Comments

@dberlow
Copy link
Collaborator

dberlow commented Jan 14, 2024

Dave asks if we can provide prototype glyphs for testing development of these two axes, first described on variationsguide.typenetwork.com

Not yet given a complete feature list, much of the axis creation for this is complete. Figures ranging from regular to numerators, and small caps, can be tested today if blending, fencing and nesting this in their target style works. What we do not yet include is shifting glyphs that are not base aligned.

The question lingering for both of those axes, is whether they can use instructions similar to the existing TT component definitions, to eventually include facility for positioning the nested blends of glyphs that way, or whether positioning is implemented by adding axes for that as part of the blending (and fencing).

@davelab6
Copy link
Member

Hopefully the VARC format can make these attainable.

https:/harfbuzz/boring-expansion-spec/blob/main/VARC.md

If FB can demonstrate Roboto Flex numeral sets and the moon phase characters as proposed in 2016 as vuid/votf, that will set stage for using VARC for fencing, I think :)

@dberlow
Copy link
Collaborator Author

dberlow commented Jan 14, 2024 via email

@davelab6
Copy link
Member

davelab6 commented Jan 14, 2024

Fontra; it's used to make varcs for locl features for localization of CJK characters from Simplified Chinese to Traditional Chinese, Kanji for Japan and Hanja for Korea; and does it at two levels, although the format supports any number of levels or even recursion. So there are 4 glyphs for one unicode character, 1 is the default encoded glyph and the other 3 glyphs are accessed via locl feature, but those 3 glyphs contain the same components as the character glyph, yet with different locations for the components in their own 'local' design spaces.

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

3 participants