LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0 (Apple Message framework v622)
Content-Type:
text/plain; charset=US-ASCII; format=flowed
Date:
Wed, 27 Apr 2005 19:06:34 +0930
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Will Robertson <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
7bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
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

ATOM RSS1 RSS2