> 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
> 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
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
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
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