At 20.01 +0100 01-02-23, Michael John Downes wrote:
>Lars Hellstr–m <[log in to unmask]> 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!