Thierry, > Quite a long time ago, it was said that "the good way to implement > MakeUppercase & friends would be to add a "case" axis to NFSS". > > I'd like to know if some activity has been undertaken to address this. other than talking about it, no, as it involves mainly work done by people who produce vf files. I still think that a "case" axis is probably the best way to think about that stuff what i mean is that it is not that difficult to add code implementing additional dimensions in a successor of NFSS2 but it would need involvement on several fronts. > 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_. i'm not sure i agree on the split for the series attribute. and it doesn't really origins in the CM history --- it does origin in "Methods of Book design" by Hugh Wiliamson. one idea with the axis' or attributes was that it should be desirable (and sensible) to change individual attributes while retaining al others. Now i claim that there is not much argument for changing individually width but retaining weight or the other way around, eg you would say: "i want my section headings in bold extended series" and the emph2 in normal text in bold-medium" ---i doubt that a design specifying titles as "extended with whatever weight comes along in the markup" or as "bold with whatever width comes along" is very likely though i would not absolutely say such a design can't exist. so my claim for the bad results is not really the deficiency of the of that decision but the non-existent design of class files in the first place (as well as not enough flexibility in the fonts available to the average user who doesn't want to or can't affort to buy good commercial fonts) > The current situation as regards "series" is not too bad because the > translation from markup to layout should be done in a class file, it > is however bad that such classes must be dependant on the font system > used. i'm not sure i understand this remark (but it is getting rather late for me so ...) --- in what respect do they depend on the font system used? i mean proper classes (not a generic one like article et al) can't cater for more than a single font set anyway, can it? but even if you think about a more generic class: that could easily ask for bold extended in titles but normal bold in text --- whether this would be honoured would be a question of which font family you use. okay right now with the .fd files containing substitutions that are geared towards latex always asking for bx the results might not be as good as they could be and granted that the substitution mechansim for selecting a font when the requested one is not available is too simple-minded (but then this *is* an error situation in a production environment) again you might not get the best possible, but i'm not convinced that splitting the series axis would improve that situation. in fact my guess is that such a split would make things worse as the number of combinations without a real font behind it, ie which would result in the system to decide on an alternative, would grow and any such error situation is likely to be resolved incorrectly (even with smarter algorithms like the one in NFSS2) improvement would come through better class design imho > the "case" axis is really needed, and will be ever, since unicode i agree with that (even though i don't go with the unicode argument (with all the flaws that has by trying to be several incompatible things in parallel) but it is getting too late for me good night frank