Missing variable font values ("font-variation-settings") over plugin/rest api

Hi @MKitPlug, Thank you for sharing your thoughts on this!

While we await input from our community, I’ll check internally to see if we have any additional information on this. We will update you once further information is available.

Also, I am unsure, but I came across a similar post at this link: Missing variable font values in style Please feel free to take a look!

Thank you for your input, and if anyone in our community has any insights, please feel free to vote or comment to support this idea!

Hello @MKitPlug, I’ve looked into this matter internally and unfortunately, it is not currently feasible.

However, we’re already aware of the demand for it. I have included your suggestion in our internal report to bring more attention to it.

Thank you again for your valuable input!

​@Junko3 I’d like to also note a certain nature of this demand: Without plugin API access, there are no workarounds at all other than manually selecting individual text nodes and modify values. This significantly limits a team’s ability to deploy variable fonts at scale reliably. You can’t do that manually with millions of frames.

Hello ​@Junko3 , 

Are there any news about possible developments in this regard? 

Have you found any workaround for this? ​@MKitPlug?

​@Junko3 We would highly appreciate any news here. We are also missing the lack of variables there….

​@Qinyi_Yao You can use styles to reduce manual effort at least by a bit, but you are still not able to sync design and code properly without api issue solved. 

What have you done meanwhile to cope with the situation?

​@Junko3 is there any update on this? Very much needed in my organisation.

Hi All, thanks for continuing to chime in here! 

To give you all an update on where things stand, the Plugin API and REST API still don't expose variable font axis values, so there's no way to read or set wght, wdth, slnt, or opsz programmatically. Named instances do work, if your font ships a style like "Inter V Semi Bold," you can load it via loadFontAsync({ family, style }). But that won't help if you need a specific value like wght: 650, and @Qinyi_Yao is right that there's no workaround beyond that.

But good news, this is now being actively worked on with a proposal in review with our text and typography team. No exact timeline to share yet, but rest-assured, it's no longer sitting untouched.

Two quick questions, so I can pass along your use case(s) accurately:

• Which axes matter most? Mainly wght, or wdth/opsz too?
• Is your need mainly reading axis values (design → code sync) or setting them in bulk?

Thanks again for your patience here. I’ll pass your feedback onto the team while they continue to work on getting this implemented. 

Thanks for the update ​@djv . Glad to hear its being worked on!

In answer to your questions:

All Axes (including custom). We work with a range of variable typefaces that use wght, wdth, slnt, opsz as well as custom ones (serf, rond etc.). We need the api to be tag-agnostic and work with any axes in the font’s fvar table.

Read and write. We need both for our use case

In Addition, openType Features are readable but not writable. We would like to be able to get and set stylistic sets and other OT features on a text node.

The most useful and futureproof approach would be to expose everything that is in the typography panel to the API.

Do keep us updated. Thank you!