Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Apr 2005 11:56:59 +0200 Received: by mail.proteosys.com (8.12.10/8.12.2) with ESMTP id j3R9uuqc023425 for ; Wed, 27 Apr 2005 11:56:57 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.119.176]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j3R9n5fK022719; Wed, 27 Apr 2005 11:49:05 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54B0F.73D72780" Received: from listserv (listserv.uni-heidelberg.de [129.206.119.176]) by listserv.uni-heidelberg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j3QM0ID2028132; Wed, 27 Apr 2005 11:46:39 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8e) with spool id 213931 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 27 Apr 2005 11:46:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j3R9abrw016116 for ; Wed, 27 Apr 2005 11:36:37 +0200 Received: from dogmatix.mecheng.adelaide.edu.au (dogmatix.mecheng.adelaide.edu.au [129.127.14.1]) by relay2.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j3R9cQtL018872 for ; Wed, 27 Apr 2005 11:38:28 +0200 (MET DST) Received: (from uucp@localhost) by dogmatix.mecheng.adelaide.edu.au (8.8.7/8.8.7) id TAA29466 for ; Wed, 27 Apr 2005 19:11:17 +0930 Received: from UNKNOWN(129.127.14.10), claiming to be "watt.mecheng.adelaide.edu.au" via SMTP by dogmatix.mecheng.adelaide.edu.au, id smtpda29463; Wed Apr 27 19:11:15 2005 Received: from WATT/SpoolDir by watt.mecheng.adelaide.edu.au (Mercury 1.44); 27 Apr 05 19:06:35 -9:30 Received: from SpoolDir by WATT (Mercury 1.44); 27 Apr 05 19:06:34 -9:30 Received: from [10.0.1.2] (129.127.14.244) by watt.mecheng.adelaide.edu.au (Mercury 1.44) with ESMTP; 27 Apr 05 19:06:32 -9:30 In-Reply-To: <20050427075026.GD10313@mathematik.tu-darmstadt.de> References: <20050427075026.GD10313@mathematik.tu-darmstadt.de> Return-Path: X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 27 Apr 2005 09:57:00.0699 (UTC) FILETIME=[74DA66B0:01C54B0F] X-Scanned-By: MIMEDefang at proteosys.com X-ProteoSys-SPAM-Score: 0 () Content-class: urn:content-classes:message Subject: Re: new^2 font selection scheme Date: Wed, 27 Apr 2005 10:36:34 +0100 Message-ID: A<1c0fbe0520d085d2578bc565ff248163@guerilla.net.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new^2 font selection scheme Thread-Index: AcVLD3T0lsnnwWHNSDy/2eK8LGNObA== From: "Will Robertson" Sender: "Mailing list for the LaTeX3 project" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4862 This is a multi-part message in MIME format. ------_=_NextPart_001_01C54B0F.73D72780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------_=_NextPart_001_01C54B0F.73D72780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: new^2 font selection scheme

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

------_=_NextPart_001_01C54B0F.73D72780--