CatharsisFonts
Some documentation clarification would be appreciated
Hi,
Thank you for publishing a rich and complex font family. It’s both awesome and intimidating.
Am I right, when reading
It comprises a total of 45 font files spanning 9 different styles Roman, Italic, Infant, Infant Italic, Garamond, Garamond Italic, Upright Cursive, Small Caps, Unicase
that Small Caps and Unicase are available as standard opentype features in the main font files, and provided as separate font files as a convenience?
https://docs.microsoft.com/en-us/typography/opentype/spec/features_ae
(of course Infant, Garamond and Upright may also been provided in the main files as stylistic alternates, but since those are, as far as I understand, non standard features, most apps won’t use or make them discoverable by default)
If I am wrong please correct me. I am often wrong.
that Small Caps and Unicase are available as standard opentype features in the main font files, and provided as separate font files as a convenience?
Unicase is not a separate OpenType feature. It's what you get when you combine Small Caps with SS05.
(of course Infant, Garamond and Upright may also been provided in the main files as stylistic alternates, but since those are, as far as I understand, non standard features, most apps won’t use or make them discoverable by default)
Upright is derived from a separate set of masters and therefore not available through OpenType. Infant and Garamond are.
So Unicase is not exposed with the 'unic' tag in Cormorant? Ok that’s good to know. I was, indeed, mistaken.
Generally for my deployment target I try to avoid compatibility fonts for standard OpenType features, because otherwise both apps and users never learn to make use of them. Stylistic alternates are something else, they are not hugely user-discoverable, so those I push as separate files.
Thus, in Cormorant current state, that means small caps can be done via standard feature tags, and the rest, not. That’s why I needed the info, for fear of choosing wrong. Thanks a lot for providing it quickly.
It would be nice to have the info in the readme.md for others. For me, the issue is close. Thanks again.
Generally for my deployment target I try to avoid compatibility fonts for standard OpenType features, because otherwise both apps and users never learn to make use of them.
As a non-designer, I don't even have apps that know where to find the OpenType Small Caps of a font, so I'm always grateful for compatibility fonts.
Shouldn't OFL projects aim to be inclusive rather than exclusive...?
My target covers both the font and the software side of the equation.
Unfortunately, I've learnt long ago, that the only way I could make my friends app-side implement support for OpenType features, was to refrain from pushing compatibility fonts. They are nice folks but “we have a workaround” is interpreted as “will look at it next decade”. If they had their way we’d still be using 4-faces only font files with no ligatures or any smarts.
I don’t particularly like needing to choose between short-term user workarounds and good long term app support either. But, that’s how things are and I understand the human equation too.