LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

```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.

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

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.
```