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 manual). 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 font. 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 documents. Lars Hellström