LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Lars Hellström <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 2 Mar 1999 18:38:13 +0100
text/plain (98 lines)
Thierry Bouche wrote:
>It seems obvious to me that current nfss misses 2 axis, namely _width_
>("series" should be broken into weight and width, this bx as
>\bfdefault reflects TeX + CM history but has the notoriously bad
>consequence of seeing bold extended used inside text, not restricted
>to titling material) and _case_.

An alternative approach towards handling the \bfdefault problem you
describe could be to make the expansion of \bfdefault depend on the family,
so that CM has it to be bx and most other families have it to be b. (This
is just a thought, I'm not sure it is a good one.)

>the "case" axis is really needed, and will be ever, since unicode
>ignores small caps, and multiple digits shapes. (It's a unicode flaw,
>imho, to enforce the capital/small letter distinction [two glyphs for
>the same charachter, no?] and reject small caps,
>lining/hanging/tabular figures).

I disagree to the parenthesis. The distinction between upper and lower case
letter is usually prescribed by spelling rules etc., whereas the further
distinction of small caps is not.  The distinction of upper and lower case
is thus more fundamental.

>I think that adding the cases axis would be rather harmless, since
>people could simply ignore it (not the same for series vs
>weight&width) _and_ very usefull, since many have been temptated to
>turn some variant classes into families to have access to small caps
>in italic or slanted e.g.).

Why are people so stuck with the four standard shapes? It ought to be much
cleaner to simply define a few new shapes and to play around with the
...default macros a little.

>Moreover, creating the few missing fonts
>with EC would be trivial, and maybe cleaner (accents for caps should
>be in an all-cap font rather than in TS1?),

That's a point. Isn't TS1 to some extent simply the "expert" encoding for
the EC fonts?

>fontinst could similarly
>create a bunch more of VFs for supporting PS fonts as well.
>I'm thinking at least at:
>all caps (cap digits)
>c&sc (sc digits--almost inexistant in practice: cf Bell expert)
>all sc
>c&lc (lc or old style digits)
>all lc

Shouldn't c&sc have the same digits as c&lc? (I know foundries like to have
c&lc with upper case digits and c&sc with lower case, but there's no
typographical reason for that, it's just how they package their product.)
If you by sc digits mean digits with depth=0 and height=x-height then I
think those should be used with the all sc, but not with any of the other.

One thing which I miss in your list above is all caps for use in lines
mainly c&lc, for acronyms and the like. I know some people prefer to set
these in sc, but they are intrinsically upper case, so I (any many others)
would rather have them in this special all-caps. In practice this special
all caps would probably be realised either using medium glyphs or as the
all caps at a slightly smaller point size (DEK does this in the WEB user

Roozbeh Pournader wrote:
>Thierry Bouche suggests using anothe font for \MakeUpperCase.

Well, so does the LaTeX2e fontguide (fntguide.tex).

Yannis Haralambous wrote:
>I don't think this is the good way, as a matter of fact it cannot
>work: uppercase/lowercase/smallcaps is language dependent, and as far
>as I know there is no language axis yet in NFSS.

Aren't you sort of confusing cause and effect here? By writing in a
specific language the author determines which frame of typographical
conventions should be used when typesetting the text (or in our case rather
marking it up). You can't require that NFSS should not offer a specific
font because it isn't used in the specific frame of typographic conventions
that applies to your text, it is your responsibility to not choose that

Language-dependent macros, in the extent that there are any around, exist
on a much higher level than the NFSS macros.

I think I like the idea of a case axis. I don't like having c&sc on it,
since I think that rather belongs on the current shape (n-sl-it) axis, but
I realise its appearence on a case axis is inevitable. I am however
satisfied if sc will remain to exist on the shape axis. Removing it is
(luckily) probably not possible since that would break lots of old

Lars Hellström