## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Proportional Font Show Text Part by Default Show All Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Re: new^2 font selection scheme Will Robertson <[log in to unmask]> Wed, 27 Apr 2005 19:06:34 +0930 text/plain (63 lines) On 27 Apr 2005, at 5:20 PM, Achim Blumensath wrote: > the MinionPro project was asked about our wishes for an improved font > selection scheme. Currently there are three things which we miss in > NFSS: > > o Separate values of \bfdefault,... depending on the font family. > > o Support for many-dimensional font shapes. We need: > - one axis for roman/italic/swash, > - one axis for u&lc/small caps/spaced small caps/versals, > - one axis for text figures/lining figure, and > - one axis for proportional figures/tabular figures. > > o The ability to change math fonts within the document. Currently, > \SetSymbolFont and friends are declared \@onlypreamble. This is > needed, for example, to switch to tabular figures when setting > tables. I believe that there will never be a fixed scheme that is able to encompass all variations that can be thought up by a font designer, so simply adding more axes in the NFSS is the wrong way to go about things, IMO. For example, in the above list there is no support for a width axis decoupled from the weight axis, and there are many font families that contain such. What about the minefield of font features defined in AAT and OpenType? These must be handled in a more extensible manner. In my opinion, a small number of axes should be added to the NFSS. At current we have:    1 Encoding    2 Family    3 Shape    4 Series    5 Size I would propose the following for a replacement: (order is not important)    1 Family    2 Encoding    3 Size    4 Shape (roman, italic, swash)    5 LetterCase (normal, small caps, petite caps if necessary)    6 Weight (light, normal, bold)    7 Width (condensed, normal, extended) If, as undoubtedly will happen, font features are required, then these could be provided by extensibly altering the current family. This latter idea is what the fontspec package currently does for accessing rich font features in XeTeX-based LaTeX. It has built in support for a wide range of OpenType and AAT font features -- too many to accommodate with an ever increasing number of NFSS axes. Rather a system like as shown in Peter Lehman's fontinst (he calls it nfssext.sty) is more appropriate. In summary, I think a thorough re-implementation of the NFSS, rather than a simple extension, is what is required in order to take rich font features into account. Will Robertson