[csswg-drafts] [css-fonts] font property for OpenType 'case' & 'cpsp': Case-Sensitive Forms and Capital Spacing (#6782)

mfishma has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts] font property for OpenType 'case' & 'cpsp': Case-Sensitive Forms and Capital Spacing ==
As recommended by and [answer on Stackoverflow](https://stackoverflow.com/questions/60869623/opentype-capital-spacing-cpsp-in-css-without-font-feature-settings), I'm starting a discussion for these common OpenType features. 

There are two common OpenType font features settings that don't have a typical way to enable in a cascading way, other than font-feature-settings. 'case' and 'cpsp'

**Case-Sensitive Forms** of fonts, 'case' definition from [microsoft.com](https://docs.microsoft.com/en-us/typography/opentype/spec/features_ae#tag-case):
> Shifts various punctuation marks up to a position that works better with all-capital sequences or sets of lining figures; also changes oldstyle figures to lining figures. By default, glyphs in a text face are designed to work with lowercase characters. Some characters should be shifted vertically to fit the higher visual center of all-capital or lining text. Also, lining figures are the same height (or close to it) as capitals, and fit much better with all-capital text.
**Example:** The user selects a block of text and applies this feature. The dashes, bracketing characters, guillemet quotes and the like shift up to match the capitals, and oldstyle figures change to lining figures.

Note that this calls out punctuation and oldstyle figures, but 'case' could affect certain letterforms such as a diacritic hook.

**Capital Spacing** 'cpsp' from [microsoft.com](https://docs.microsoft.com/en-us/typography/opentype/spec/features_ae#tag-cpsp): 
> Globally adjusts inter-glyph spacing for all-capital text. Most typefaces contain capitals and lowercase characters, and the capitals are positioned to work with the lowercase. When capitals are used for words, they need more space between them for legibility and esthetics. This feature would not apply to monospaced designs. Of course the user may want to override this behavior in order to do more pronounced letterspacing for esthetic reasons.
**Example:** The user sets a title in all caps, and the Capital Spacing feature opens the spacing.

Here's with both applied. There's only a subtle change to spacing that truly shows up by noting the last character shifts to the right slightly.
![caps-alt-teleNeo](https://user-images.githubusercontent.com/1066582/139508937-1797d6dc-cd9f-4c81-943c-c4b79d177117.gif)

**Recommendation options** - apologies, I'm not sure how the decision-making process has been done in the past, nor am I familiar enough with #5799 to know if this would solve this.
1. `text-transform: uppercase` could institute both of these. If 'case' characters exist, and if 'cpsp' is defined, use them, if not, it would fallback to the default. The problem is that you could have a lowercase letter that could benefit from 'cpsp' being amongst capital letters, so unsetting text-transform for one letter would change the spacing. No biggie.
2. `font-variant-caps: all-caps` could activate both 'case' and 'cpsp,' but would still require `text-transform: uppercase` to make sense-- so the system forces that, or leaves it to the developer to activate. It would likely override oldstyle figures in this way.
3. `font-kerning: capital` (I assume _uppercase_ or _all-caps_ is taken) could set or (or unset with `normal`) only 'cpsp', and `font-variant-alternates` would set a value in a way that adds the 'case' alternate characters.

The solution should allow lowercase characters to be used when needed.  For example, in an all-caps style, the _iPhone_ would need to appear as _iPHONE_. Thus, having 'cpsp' might still be desired for kerning, while a class could turning off uppercase and 'case' for that one letter.

Thanks for the discussion!

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6782 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 29 October 2021 23:02:44 UTC