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
Javier Múgica de Rivera <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 5 Dec 2006 00:52:25 +0100
text/plain (111 lines)
More thoughts on the subject:

It is painful to type \font\foo=foo12 for every font you need, and even 
more problematic, if it is decided to change the family, the size, or 
some other aspect, all the definitions of fonts need to be changed. Thus 
the need of font selection schemes. The idea of a font selecction scheme 
is that a user can type \bfseries and the current font automagically 
changes to the bold version of whatever it was at that point. Boldness 
is just une feature among many others that different variants from a 
font family may have. Any attempt to gather in a list all the posible 
features a font may have will fail, for it is an open problem, let alone 
unique. For some scripts other than the familiar latin, greek and 
cyrilic, some of the basic features do not even apply. For example, 
arabic and persian scripts do not have the contrast serif/sans serif, 
and do not have smallcaps, as was pointed in this list some years ago. 
Restricting ourselves to a latin script, some "artistic" fonts very 
likely provide only size variants, while others such as cm or lucida 
have plenty diferent variants with respect to several features and many 
of the posible combinations thereof. So one could start by thinking that 
the font switching commands be font-family dependent, and be provided by 
each family package. This would however lead to a severe compatibility 
problem. On the one side, if we decide to change the family for a 
document or a fraction of it, we would need to change all the font 
switching commands accordingly, for one font may call it \bold, while 
the other may call it \bfseries. On the other side, any macro that deals 
with fonts, such as a macro for typesetting a bold section header, would 
just work with the fonts that happen to make use of commands with the 
same name and the same meaning.
So, what does the current font selection scheme provide?:

a) The size axis, which is essential.
b) The encoding axis, wich has turn to also be essential, although it 
took a time to realise, I think.
c) Uniformity in the command names for some usual features (\bfseries, 
\itshape, ...)

It has the problem that the definition of these commands is hardwired. 
For example, \bfseries selects the font associated to the command 
\<enc>/<fam>/<shape>/bx/<size>. A very well implemented mechanism of 
substitutions is provided, I know, but it does not prevent the bx pair 
of letters to be needed to be placed into the fourth argument (axis) of 
the font definition command \DeclareFontShape. So in order to provide a 
comprehensive selection scheme the FSS would need as many axis as a 
single family may need. Note that I say "as many as a **single** family 
may need". Each particuar axis, apart from enconding and size (and 
possibly family), simply exists, and can be conceptualy thought by any 
font family as it needs it. Even if it were not a high number of axis, 
it would lead to a completely useless combinatorial explosion of 
commands for fonts than just implement a few axes; either directly in 
the font definition files or generated on the fly by the \Declare... macros.

The solution I see is the following one:
1) We make a list of names of user-level commands representing 
particular font features to be followed by any font that implements 
them. For example, \outline, \condensed, \shaded, \porportionalfigures, 
\trafficlike, \iranic, \novowels (This last for hebrew and others, if it 
makes sense).

2) We let those commands to be defined by the family. Therefore, when 
the family is changed, Latex has to take the definitions for the newly 
selected family.

The point 1 guarantees that if you are in possession of a font with 
outlined and shaded variants you can use a macro designed by someone for 
typeseting an outlined heading with a shaded initial and it will always 
work. Some command could be decalred to take arguments, for example, 
\boldness{<number>}, \slantness{<number>}, where standard values for  
<number> should also be given. It is similar to the LICR, but instead of 
dealing with characters it deals with font features.
The point 2 seems to me unavoidable. As I said, the feature 
classification is not closed nor unique, so a hardwired system of axis 
as the present one (or a hardwired system of whatever) will always be 
incomplete. This would make font families one more of those kind of 
entities that completely redefine a set of macros. Now I can think about 
languages and encodings.
I think that it wouldn't be ifficult to implement it. We simply define 
\outline (say) to be

\def\outline{\csname \font:fam/outline \endcsname}

(where \font:fam stores the current family). Then every font package 
would define the features that it implements. For example, the package 
times could define:


Latex would also keep track of the encoding and size, to be stored, for 
example, in \fam:enc and \fam:size. But it does nothing more than 
storing them. Each font package would make use of them in the definition 
of its \<fam>/<feature> commands. This allows each family to implement 
the substitution and orthogonality mechanism that it considers better 
suited for it, as well as definig missing  usual features as 
substitution+warning (of substitution+error). For example, a family foo 
that is itself calligraphic, could define \foo/italic to issue a warning 
and do nothing (continue without any font change), just in case a user 
uses (or uses a macro that makes use of) the command \italic while 
typesetting text with that font.
This scheme does not prevent Latex from suppling useful commands for the 
definitions of the fam-feature commands (\DeclareFontAxis, 
\DeclareFontFeature, or whatever). Nor would the list of standard 
features be closed (as is not the LICR).

Time to sleep, bye.
Javier A.