Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f1OEHxr11211 for ; Sat, 24 Feb 2001 15:18:44 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1OEHws16373 . for ; Sat, 24 Feb 2001 15:17:58 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1OEHwH21705 for ; Sat, 24 Feb 2001 15:17:58 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09E6C.B19EBA00" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id PAA11515 for ; Sat, 24 Feb 2001 15:17:58 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1OEHvH21701 for ; Sat, 24 Feb 2001 15:17:57 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <6.67D3A1CF@mail.listserv.gmd.de>; Sat, 24 Feb 2001 15:17:46 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 493140 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sat, 24 Feb 2001 15:17:53 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id PAA03374 for ; Sat, 24 Feb 2001 15:17:52 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id PAA15376 for ; Sat, 24 Feb 2001 15:17:53 +0100 Received: from mail.umu.se (custer.umdac.umu.se [130.239.8.14]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1OEHqh12283 for ; Sat, 24 Feb 2001 15:17:53 +0100 (MET) Received: from [130.239.137.13] (mariehemsv093.sn.umu.se [130.239.137.13]) by mail.umu.se (8.8.8/8.8.8) with ESMTP id PAA28610 for ; Sat, 24 Feb 2001 15:17:51 +0100 (MET) In-Reply-To: References: Lars Hellstr-m's message of "Fri, 23 Feb 2001 19:39:22 +0100" Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id PAA03375 Content-class: urn:content-classes:message Subject: Re: insufficent NFSS model (?) Date: Sat, 24 Feb 2001 15:17:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4013 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09E6C.B19EBA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 20.01 +0100 01-02-23, Michael John Downes wrote: >Lars Hellstr-m writes: > >> 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. > >I think "all uppercase" should either go into a separate axis or be >combined with the font encoding. I was describing a solution for the separate axis model, since that is = what Thierry originally suggested. >If lu, ll, uu are handled through the font encoding then it leaves only >small caps to be handled through the font shape. Something like >T1/.../.../sc for cap&small caps, T1L/.../.../sc for all small caps, = and >T1U/.../.../sc identical to T1U/.../.../n. Wouldn't that be a frightful waste of hash table space? You can't use = the same font for either of lu, ll, or uu because A-Z and a-z have to go = right, so the definitions for the encoding-specific commands in the T1, T1L, = and T1U might just as well be identical, but then you end up using three control sequences for every control sequence currently being used. OTOH, I'm not suggesting that sc as a shape should be abandoned; I would even continue to use it as such, because that is how I perceive it. = There are however those who e.g. want to be able to select a font that is both italic and smallcaps! Lars Hellstr=F6m ------_=_NextPart_001_01C09E6C.B19EBA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: insufficent NFSS model (?)

At 20.01 +0100 01-02-23, Michael John Downes = wrote:
>Lars Hellstr–m = <Lars.Hellstrom@MATH.UMU.SE> writes:
>
>>    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.
>
>I think "all uppercase" should either = go into a separate axis or be
>combined with the font encoding.

I was describing a solution for the separate axis = model, since that is what
Thierry originally suggested.

>If lu, ll, uu are handled through the font = encoding then it leaves only
>small caps to be handled through the font shape. = Something like
>T1/.../.../sc for cap&small caps, = T1L/.../.../sc for all small caps, and
>T1U/.../.../sc identical to T1U/.../.../n.

Wouldn't that be a frightful waste of hash table = space? You can't use the
same font for either of lu, ll, or uu because A-Z and = a-z have to go right,
so the definitions for the encoding-specific commands = in the T1, T1L, and
T1U might just as well be identical, but then you end = up using three
control sequences for every control sequence = currently being used.

OTOH, I'm not suggesting that sc as a shape should be = abandoned; I would
even continue to use it as such, because that is how = I perceive it. There
are however those who e.g. want to be able to select = a font that is both
italic and smallcaps!

Lars Hellstr=F6m

------_=_NextPart_001_01C09E6C.B19EBA00--