- From: Adam Twardoch (List) <list.adam@twardoch.com>
- Date: Mon, 22 Mar 2010 09:17:49 +0100
- To: www-style <www-style@w3.org>
- CC: John Daggett <jdaggett@mozilla.com>
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 Monday, 22 March 2010 08:18:24 UTC