small-caps should return OTF small-caps/uppercase

[elmimmo]

For lowercase text whose style is font-variant: small-caps;, such as:

<p style="font-variant: small-caps;">abc</p>

glyphhanger should return:

• either native OTF small-caps, if the font has them,
• or uppercase text (in the example above, ABC), since that is what the browser will fall back to if not.

or, optionally, both, since support for native OTF small-caps, even when the font has them, depends on the rendering engine.

Now, glyphhanger simply returns the original abc. Therefore, a font subset with glyphhanger will not contain, in this case, the glyphs that the browser needs.

Interestingly, <p style="text-transform: uppercase;">abc</p> does return ABC.

[zachleat]

A ha. Hmm—we have special code to handle text-transform values uppercase, lowercase, and capitalize.

A few thoughts:

• We don’t strip opentype features so those will be maintained (although that might be a potential savings if the parent characters don’t exist in the subset—I wonder if pyftsubset does something fancy there? not sure)
• It seems like the uppercase text will be needed if the font file does NOT have smallcaps glyphs, which would require more font internals knowledge than we currently have access to? See #36 and opentype.js.
• We do have special code for capitalize that has a safer (but not 100% ideal) workaround—given that there are special language-specific rules for this—we just punt and both uppercase and lowercase there (see #25 (comment)). We could include a similar case for this where we just include the uppercase if small caps are in play (as you suggested).

[zachleat]

Additional note (TIL): while font-variant: small-caps does fallback to fake/synthetic small-caps, font-feature-settings: 'smcp' on shows lowercase as a fallback (no fake/synthetic small-caps).

[zachleat]

This will be included with v3.1.0—thank you for this lovely issue, I enjoyed working through this one 👍

Please let me know if you have any other trouble!