isVariable -> list of axes

[davelab6]

isVariable is extremely useful since a family name by itself will not reveal if a font is variable, or not. While https://github.com/inexorabletash/font-table-access will allow developers to create their own JS libraries that f.getTables([ "fvar" ]); and list the axes, it may be more convenient for developers (especially less savvy ones, like CSS-only sort of folks) to be able to know what axes are in a family that is enumerated with this API.

[yisibl]

I need this parameter too.

In the font list, I can't distinguish between the different weights of the variable fonts, they all have the same full name.

Demo: https://font-access-api-to-svg.glitch.me

[yisibl]

Hi inexorabletash, is this API still being actively improved?

The tech() function has been added to css-fonts-4 to detect various characteristics of fonts.

Can we consider aligning with the CSS specification and return the tech of the font.

<font-tech>= [<font-feature-tech> | <color-font-tech>
 | variations | palettes | incremental ]

<font-feature-tech>= [feature-opentype | feature-aat | feature-graphite]

<color-font-tech>= [color-COLRv0 | color-COLRv1 | color-SVG | color-sbix | color-CBDT 

The variations here correspond to isVariable.

cc @garretrieger @svgeesus @litherum @drott

[tomayac]

Mentioning @inexorabletash, since he was "mentioned" without '@' above.

[svgeesus]

Small correction: note that this is now:

<font-format>= [<string> | collection | embedded-opentype | opentype
 | svg | truetype | woff | woff2 ]

<font-tech>= [<font-features-tech> | <color-font-tech>
 | variations | palettes | 
   incremental-patch | incremental-range | incremental-auto ]

<font-features-tech>= [features-opentype | features-aat | features-graphite]

<color-font-tech>= [color-COLRv0 | color-COLRv1 | color-SVG | color-sbix | color-CBDT ]

[inexorabletash]

Re: is this API still being actively improved?

Yes, but at least on the Chromium side our current focus is on performance work to improve the blob loading, and it's not the highest priority work for our team.

Re: tech() - interesting suggestion!

In theory, this request (font tech) can be done in JS by getting the font blob and parsing the tables, can it not? i.e. any such proposal could be polyfilled. Anyone up to take a stab at it? That would also help inform implementations and tests. I'd love to hear statements from developers about why a JS solution is insufficient - e.g. the code size is too great, the performance of loading each blob is poor, etc. This helps with evaluating the priority of the work.

Also, any interest in helping along on specifying proposed additions would be welcome.

[drott]

The tech() function has been added to css-fonts-4 to detect various characteristics of fonts.

Can we consider aligning with the CSS specification and return the tech of the font.

Note that these tech() are used with a slightly different intention in the src: descriptor. There they are a resource selection filter. And the UA selects in order of appearance any resource for which the UA understands or can process the specific tagged resource.

For an API where you want to learn something about the technology of the font, like calling something like fontType() or fontTechnology() on a font object, I am not sure these are the best fit. Or generally, I am not certain there is a good way to define such an API that fits everyone's use case. In particular, as the tech() attributes can overlap: a COLRv0 and V1 font can be variable. A font can have SBIX and COLRv1 glyphs in the same font. So a font's characteristics cannot generally be mapped to single return value cannot out of those.

Then the question is: What would be good return values, and what would make such an API better than returning a list of table tags?

An axis enumeration is well-defined and may make sense and implicitly tells something about whether the font is practically variable or not. On the other hand, retrieving that table and parsing fvar in a JS lib is not too much overhead either for someone who needs that.