## 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 >>]

 Subject: Re: Small caps is not a shape From: Frank Mittelbach <[log in to unmask]> Reply To: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Thu, 10 Apr 1997 20:17:34 +0200 Content-Type: text/plain Parts/Attachments: text/plain (59 lines)
```Johannes Kuester writes:
> This is to point at a shortcoming of NFSS2: (I don't know whether
> this has already been discussed when designed NFSS)

this has been discussed both during and after development of NFSS2

> There is such a thing as a slanted/italic small caps font
> (see Sebastian Carter's "Typographers on Type" for an example:
> it contains a page showing different fonts of the Zapf Renaissance (1986)
> family, including such a font).

agreed, calling small caps a shape is a simplification. similariy for
making, say "outline" a shape

> So it doesn't seem appropriate to classify small caps as a shape,
> rather, I think, it should be considered as a case. Thus resulting
> in control sequences like
>   \textcaps{...} and {\capscase ...}
> or the like, analogous to uppercase and lowercase.

again, agreed in principle; having "case" as a further axis to the FSS
would be a valid possibility

> Unfortunaly I can't think of any way to incorporate this easily
> in NFSS and especially in its current interface.

it would be easy enough to integrate it in the general model, but
there are downsides of it as well:

- no way to integrate it into the specification interface without
either a horrible syntax or incompatible changes

- nfss is designed to model major font use faithfully, adding an
additional axis that is only sparsly populated would result in a
large number of additional cases where font substitution rules need
to be applied. that in turn would either blow up substitution rules
ro would result in badly rendered documents.

so as far as latex2e is concerned, there will be no modifications
(Robin sumarised the reasons for that quite well). I do have plans for
a different fss that deals more intelligently with encoding issues and
with substitution. for that implementation a fifth "case" axis will be
considered (and perhaps even be implemented :-) or perhaps even a more
general scheme with arbitrarily many axis', although the latter i do
find still questionable.