As various modifications of NFSS are again being discussed, I might as well post the following text, which I thought up after the last time related matters were discussed. It concerns the suggested addition of a "case" axis to the NFSS model, and in particular how the positions on that axis should be named. It is hardly something directly useful at the moment, it's rather something you keep in the drawer until you start coding, but this is no worse time to present it than any other, so here it is. Lars Hellström *** A naming system for cases It has been mensioned that NFSS3, when it eventually will be written, will add a `case' axis to the axes that are used for denoting fonts in current NFSS. Thus the need arises to have names, i.e., short letter sequences that denote positions on this axis, for the cases. I have spent some time constructing a system for this, and here I present the result of this. The main idea behind the system is that most fonts consist mainly of letters, and that these letters form two distinct alphabets. One alphabet appears in the character positions for majuscles (``the upper case'') and one appears in the character positions for minuscles (``the lower case''), but exactly which alphabets are used for majuscles and minuscles respectively varies between the different cases. Among the fonts in the basic set of cases, there are three different alphabets that occur, namely * the lower case alphabet, * the upper case or full captials alphabet, and * the small capitals alphabet. Simply by specifying which of these have been used for majuscles and which have been used for minuscles, one can specify all five cases that were requested by Thierry Bouche back in 1999, namely: upper- and lower case, caps and small caps, all lower case, all upper case, and all small caps. By writing `l' for the lower case alphabet, `u' for the upper case alphabet, and `s' for the small capitals alphabet, and furthermore by writing the minuscle alphabet first and the majuscle alphabet second, one gets the names: lu for upper and lower case, su for caps and small caps, ll for all lower case, uu for all upper case, and ss for all small caps. It might seem more logical at first to begin with the majuscles, but it is my (subjective) impression that the names generated that way do not look as nice. Furthermore, most letters in a text are minuscles, so it is logical for them to take precendence, and this also avoids possible name collisions (not in NFSS, but perhaps in package writers' macros) between `lu' (upper and lower case) and `ul' (ultra light). Now what are the advantages of this system over the naive method of simply abbreviating the case names that were written out in full above? To begin with, those case ``names'' are descriptions rather than proper names, and hence abbreviating them certainly wouldn't make things any better. One should furthermore observe that the entire `case' concept is something which makes very little sense in traditional metal type typesetting; it only becomes interesting in computerized typesetting, where the types/glyphs are collected in fixed sets (the fonts). A consequence of this is that there hasn't been that much time for names of cases to evolve in. Those that come close are `CSC' and `all-caps', but one cannot base an entire system on just these two. Alphabet, in the sense used above, is on the other hand a concept which has made sense throughout the history of printing, and consequently there are proper names for these. (I don't think the names used in English are very good, as they seem to form two distinct systems which are both incomplete, but since English is the language of our discussion, I suspect we're stuck with them.) Thus a system based on the alphabets has a much better anchorage in typographical tradition than one based on the cases as such. Another advantage is that the set of available alphabets is rather small, compared to the set of cases that can be formed from them. Virtual fonts allow users to combine alphabets in rather arbitrary ways, but creating additional alphabets usually requires other means, which are not as freely available, and which require a good deal more work. Therefore one can expect that the set of alphabets is going to remain fairly constant once the initial phase of experimentation is over, whereas the set of realized cases is likely to grow for quite some time, since there simply are so many possible cases, and keeping a list (including descriptions) of them all can be quite some work. *** Some additional alphabets The `l', `u', and `s' alphabets certainly are the basic alphabets, but there are at least two other alphabets which definitely should get codes. Some of these are listed below. Medium capitals: The obvious choice here seems to be `m'. The medium capitals are often called in question, and it is clear that some typographic traditions make no use of them, but other traditions do. In e.g. tex.web we find the lines: \font\ninerm=cmr9 \let\mc=\ninerm % medium caps for names like SAIL and I suspect that this will be the usual way of implementing them: as the upper case of a smaller font size. Note that the fact that there is a standardized designation for medium capitals does not by any means imply that font designers will have to implement them, or even if they do, that they have to be visually distinct from e.g. the full capitals. The purpose of this system is only to let people know what they should call something if they choose to provide or request it, not to establish some set of "required font variants". Superscript lower case: Many expert fonts contain a (partial) alphabet of superscripted lower case letters. As `s' and `u' are already taken, the letter `p' seems suitable as a designation for this alphabet. I can't pretend that I know an application for it, but a `pu' case font could for example provide a properly kerned M\textsuperior{me}. *** Everything isn't letters Fonts are not comprised by letters alone, however, so just describing minuscles and majuscles is not a complete description of a font. In particular there are figures and punctuation marks, and for those I would like to propose the following rule: IF NO ADDITIONAL SPECIFICATION IS GIVEN THEN THE APPEARENCE OF THOSE CHARACTERS IN THE FONT WHICH ARE NOT LETTERS SHOULD BE THE ONE THAT THE FONT DESIGNER FINDS MOST AESTETICALLY SUITABLE. In particular, one cannot as a user who is writing a document which is supposed to work regardless of what font family it is typeset in assume that all figures have the same width, as the choice of whether to use one set of figures or another is up to the font designer to make. Unless, of course, the font selection includes a specification that the figures should be fixed-width (in which case the user who tries to typeset the document with fonts that do not provide such figures will see a warning that precisely the requested font did not exist). This may be a bad example, since I doubt that the case attribute is the proper one for that kind of specification, but it illustates the general idea. What _can_ one select using cases, then? Mainly what kind of letter alphabet the figures should look like. The basic distinction of different types of figures is that between `hanging' and `lining' figures, which is very much like the distinction between lower case letters and capitals. Therefore I would like to make the following "alphabet" classification of figures: l - hanging figures u - lining figures that line with upper case letters s - lining figures that line with small capitals m - lining figures that line with medium capitals p - superscripted figures b - subscripted figures One could make further distinctions in the `p' and `b' cases, but that doesn't seem meaningful right now. My suggestion is that if the case name contains a third letter, then that letter should be interpreted as a request for a particular type of figures. In most cases there is little reason for making such requests, since there is only one type of figure that works typographically, but merely having the notation makes it much easier to express oneself in writing about these matters. One can for example point out that the `uu' case should be a `uuu' case, since the figures should line with the letters, and similarly that `mm' case should be a `mmm' case and the `ss' case should be a `sss' case (mind you, I've occationally seen lines in adverts that were written in the `ssl' case, and it didn't look that wrong, but it might well have done so if the numbers were different). The case where the room for variations is greatest is the `lu' case, since neither hanging nor lining figures have a clear priority here (when different traditions are averaged out). It is interesting to notice however that most existing fonts which have lining figures, such as e.g. cmr, do not exist in the `luu' case, but in the `lum' case, since the figures do not line with the upper case, but instead are slightly smaller. (This is typographically quite correct, but can be a nuisance in cases where one would want the capitals and figures to line. It also means that one usually has to scale the figures in the VF for a `uu' case font when building it on commercial fonts.) *** Fonts without cases Finally, one shouldn't forget that for some fonts (maybe even most fonts?), the case concept makes no sense. NFSS3 should provide some way of declaring a font that assigns it to all cases, so that there aren't unnecessarily any warning messages for font substitutions. End of message.