Re: font-variant-caps: all-small-caps

Getting back to this, vis-a-vis the discussion at yesterday's meeting...

I agree with Adam. Case transformation is not always a lossless process, so relying on a technique which takes characters from uppercase to lowercase and back to uppercase (small caps) is clearly worse that simply going from one style of uppercase to another (i.e. uppercase -> small caps).

And yes, the 'c2sc' feature often does contain stylistic alternates intended to harmonize with all-small-caps settings. For example, some fonts will include a set of numbers, currency and punctuation (e.g. parentheses, exclamation point) to be used in all-small-cap settings. These will not appear as intended when text is first converted to all lowercase, then 'smcp' applied.

Adam, regarding this:

> Some fonts can have "smcp" lookups and then "c2sc" lookups that rely on the preceding "smcp" lookups, so an intended result is produced when both features are applied.

Can you cite an example? Just curious.

-Christopher



On Mar 22, 2010, at 1:17 AM, Adam Twardoch (List) wrote:

> John,
> 
> On 10-03-01 09:54, John Daggett wrote:
>>> For example, the small-cap variants of certain uppercase Greek letters
>>> may be different than the small-cap variants of their lowercase
>>> counterparts.
>>> 
> Forget it, this is not a good example :)
> 
>>> The transformation would also not work for certain
>>> Unicode characters that do not have a lowercase variant (e.g. U+1E9E:
>>> ẞ). 
>>> 
>> What would a font show for this character with 'c2sc' applied?  The small-caps
>> version of 'ss'?
>> 
> No, a small-cap version of ẞ.
> 
> The lowercase form of ẞ is ß, and the uppercase form of ß is SS, because
> that's the official German spelling rule. The uppercase ẞ letter has
> been added to Unicode for purposes where the user explicitly wants to
> use such form, ignoring the official German spelling rule. When ẞ is
> lowercased, the font may apply the official German spelling rule and
> produce a smallcap version of SS, but when a smallcap of ẞ is produced
> directly, a specially-designed smallcap ẞ glyph can be used.
> 
> There are more cases like that: Imagine a web page encoded using the
> MUFI Private Use Area codes, or other PUA conventions. The web browser
> will not know how to apply the casing transformation to produce
> lowercase variants, since to the web browser, the PUA codepoints are
> "caseless". But a properly-made font will "know" which "uppercase"
> glyphs assigned to the PUA codes should be replaced with smallcap
> glyphs. This is also important for minority scripts and characters that
> will continue to use PUA because they'll never get encoded in Unicode --
> yet a properly developed font can include appropriate smallcap variants
> that work on the glyph level. In medievalist, liguistic and
> minority-language environments, that often rely on special encodings and
> special fonts, text-transform: lower-case will not work reliably.
> 
> And what if new characters are added to Unicode? A font may include
> smallcap rules for those characters, but the internal case-mapping in
> browsers may not be updated for a while.
> 
> Also, the OpenType specification, and therefore OpenType font
> developers, rely on the fact that the smalcapping mechanism is done
> through a combination of "smcp" and "c2sc". Some fonts can have "smcp"
> lookups and then "c2sc" lookups that rely on the preceding "smcp"
> lookups, so an intended result is produced when both features are applied.
> 
> If the author wants to use the "text-transform: lower-case;
> font-variant: small-caps" combo, they she or he is free to do so. But
> this does not have to lead to the same results as "font-variant:
> all-small-caps". Also, I think the text-transform: lowercase;
> font-variant: small-caps is a "trick" that is somewhat counter-intuitive
> to many authors. Of course the author is free to use
> font-feature-settings: "c2sc=1,smcp=1", but that again is also
> counter-intuitive. The practice of typesetting entire lines in pure
> small caps is very widely widespread.
> 
>> Why is this something that can only be done when 'smcp' is enabled?  Is
>> this just because one can't assume that there are no uppercase forms
>> (e.g. '(Apple)')?
>> 
> The point is: if you mix smallcaps with uppercase (i.e. only "smcp" is
> applied), the font developer may prefer to use the standard punctuation,
> because of the interspersed uppercase glyphs. On the other hand, when
> "all-small-caps" is applied (i.e. "c2sc" and "smcp"), then special
> all-small-caps punctuation glyphs would be used, that would be defined
> in the "c2sc" feature. Same applies for figures: for example, "smcp"
> could leave the default lining figures in place, or replace them with
> oldstyle figures, which work good in such context, but when "c2sc" is
> also applied, that feature could replace the figures with small-sized
> lining figures.
> 
> Needless to say, text-transform: lowercase is implemented in different
> ways. When I make
> <p style="text-transform: lowercase; font-variant: small-caps">Welcome
> to the World!</p>
> and then view the result in Firefox 3.6, and then copy-paste the text, I
> get "Welcome to the World!" but if I view this in Safari 4.0.5, I get
> "welcome to the world!".
> 
> The latter may or may not be what the user wants if only text-transform:
> lowercase is applied -- it's a good question, though somewhat outside
> this discussion, whether text-transform should affect the searchability
> and clipboard interaction or not. But it's quite certain that it's not
> what the user would expect when smallcaps are used.
> 
> And of course, in current browsers only the letters are reduced in size,
> not of the exclamation sign. Whether the exclamation sign would be
> replaced with a smallcap variant, depends on the font. Some fonts with
> smallcaps may retain the normal exclamation sign, some fonts may replace
> it with a smallcap version when "smcp" is applied, and some may do so
> when "c2sc" is applied. It's up to the font developer and the
> typographic context of the typeface what to do and when. But this means
> that "all-small-caps" should be done "by the book", i.e. simply: through
> applying c2sc+smcp. Not by some casing transformation tricks.
> 
>> Because of the way small-caps is defined in CSS 2.1, where resized
>> uppercase glyphs are used to simulate small caps, we would probably need
>> to define 'all-small-caps' with similar behavior.  But I'd prefer not to
>> extend that behavior to petite caps, even though that will cause
>> confusion for some authors.
>> 
> I agree. Since petite caps are a rarely used feature, force-simulating
> them would not be a reasonable choice.
> 
> Best,
> Adam
> 
>

Received on Wednesday, 31 March 2010 23:36:32 UTC