LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

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
Subject:
From:
Javier Múgica de Rivera <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 5 Dec 2006 00:52:25 +0100
Content-Type:
text/plain
Parts/Attachments:
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:

\times/boldness#1
\times/outline
\times/smallcaps
\times/mediumcaps
.
.
.

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.

ATOM RSS1 RSS2