Provide split VFs alongside full release: Sans, Sans Casual, Mono, Mono Casual

[nim-nim]

Using non-standard styles created enough problems Microsoft & Adobe had to forbid them in WWS to enable application support for large sets of styles, please do not repeat the same mistake using variable axes. Just release the fonts as Recursive, Recursive Mono, Recursive Casual, and Recursive Casual Mono (with Sans if you intend to release a Serif someday).

And please keep the naming short and succinct, many apps will behave sub-optimally in presence of long font names.

Apps have already enough problems supporting recent OpenType features, without creating artificial problems.

[arrowtype]

Hi @nim-nim, thanks for taking the time to file an issue!

Sorry, but what is "WWS"?

We will likely be working on a system to allow configurable downloads with subset axes, but in the short term, it would likely be possible to add this into the build scripts. Will update this issue at that time.

[nim-nim]

Hi @arrowtype

WWS is the most recent generic naming layer in the OpenType standard (Name ID 21 and 22)
https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids

It was defined by Microsoft and Adobe after the first one tried to do smart things with modern fonts in WPF, and found out it was not possible unless fonts become more rigorous in their naming.
https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Components.PostAttachments/00/02/24/90/36/WPF%20Font%20Selection%20Model.pdf

The default axes in variable fonts are the default WWS dimensions + optical size

Please don’t step outside those axes, if font authors re-create the same mess with non-standard variables axes, that they created before with non-standard styles, we will get the same result as before: app writers refusing to support any of them before someone like Microsoft steps in to put the house in order.

[arrowtype]

While I am happy to provide releases that are split to include only standardized axes, it is not counter to the spec to "step outside those axes" – it is planned for, so long as custom axes are given all-caps naming (as the CASL and MONO axes are in Recursive).

Fonts may use tags defined in this registry, or may use foundry-defined tags. (Foundry-defined tags can also be referred to as “custom” or “private” tags.) Foundry-defined tags must begin with an uppercase letter (0x41 to 0x5A), and must use only uppercase letters or digits. Registered axis tags must not use that pattern, but can use any other valid pattern. This ensures that foundry-defined tags and registered tags are never conflicting.

https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg#syntactic-requirements-for-design-variation-axis-tags

If the full variable font is found to perform less well than split variable fonts, I will try to inform users of that in or next to downloads. Thanks for flagging it as a potential concern! :)

[nim-nim]

Thanks for providing a version that includes only standardized axes.

Yes, the spec technically allows the creation of non-standard axes. Like it technically allows the creation of non-WWS fonts. To get a chance of support in the average app (not ultra-niche expensive designer apps) please stick to the default axes. The spec writers took a lot of time to identify a common ground app writers could target. Sticking to this common ground is the only way to get apps and fonts play nice with one another.

[mttymtt]

Stephen, you may also find this page on the Glyphs website helpful: https://glyphsapp.com/tutorials/naming

[arrowtype]

We've made split families for static fonts, but a full variable font for the primary release. The OpenType spec is the common ground apps should support. If someone needs a split VF, the FontTools instancer will make this easy enough to generate. I may chance my mind in the future if a lot of people request split VFs, but for now, I'm closing this to keep the repo tidy.