add hybrid vf / normal generator/parser

[udatny]

hey,

i add a new generator / parser to create a hybrid collection of all fonts. the motivation for that is to have one source with all the font metadata. i wanted to drop a note so that i can get some feedback if you think this will ever find its way in the main repo.

[ayuhito]

I'm not sure yet, but what would be the use case for this?

[udatny]

In summary,

Use Cases:

• Retrieve all font metadata from a single source.
• Provide all available axes in a consistent manner.
• Allow clear distinction between static and variable fonts.
• Get subsets for each font.

Benefits:

• Enable saving a custom font configuration based on axes and font family alone (static or variable).
• Access all data from one source, regardless of the font type (static or variable).

[udatny]

My objective is to have a dataset that supports a generic approach for accessing all the font metadata and font configuration via axes. My approach to rendering a UI includes mapping non-variable fonts to fictive axes for consistency, leading to a more generic UI. I may come up with a demo for that. Your codebase is the best i've found.

What I Have Implemented

• Hybrid file with all fonts and variants.
• Mapped configuration possibilities to axes (even for non-variable fonts) to provide consistency across the UI.
• Converted supported codepoint ranges to arrays with start and end codepoints, improving how ranges are represented.
• Restructured the hierarchy to place style (italic/normal) before the variant, acknowledging that style is a parent property for both static and variable fonts.

Why This Matters

• Ensuring each font has axes allows for a consistent way to offer font configuration through the UI or to generate CSS URLs.
• Providing a clear flag for whether a font is variable, even if it carries axes for static fonts, helps in maintaining consistency.

Criticisms and Concerns
However, I encountered some issues that may need addressing:

• Incomplete Data: Users currently need to consult multiple APIs (e.g., V2 API and the variable dataset) to get the full picture.
• Variable Fonts: These fonts lack Unicode ranges or subsets and only provide WOFF2 URLs. Additionally, the V2 API doesn’t cover variable font capabilities.
• Standard, Full, and Wght Styles: It’s unclear why these distinctions are necessary
• Italics Handling: The handling of italics is inconsistent. Some variable fonts have an italic axis, while others don’t. Also, mapping italic to an axis feels awkward since it's not queryable via the CSS2 endpoint. Thre truth about an existing italic axis is primarly given by the font itself. But it seems that the italic style in the google api data is valid.

I've attempted to keep all outputs compatible with existing formats, but I'm unsure how backward-compatible the solution needs to be—especially when it comes to providing variable fonts as dedicated files. i dont insist on merging anything.

[ayuhito]

I definitely see the merits in this approach and it would certainly improve certain aspects of dependent codebases like the Fontsource packager, website, and API. I'd even be open to releasing a major release v7 for google-font-metadata to clean it all up.

The main issue is that I don't have the time to make this work with the existing Fontsource codebases and actually leverage it. I'd be open to other people taking responsibility for it, but I'm not sure if I'd want to merge this if there's no follow up on it. The current system works by itself and I try to touch it as little as possible to not break anything 😅