[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About atomic encoding


Well, perhaps my last posting needs some additional explanations:

The idea was that, since the math core font is likely going to
hit the 256 character limit, we might have to resort to a couple
of different math core fonts customized for different disciplines.
These fonts would have quite a large number of characters in common
(this is what I called the required part in my previous posting),
but they would differ in the selection of some special characters
(which I called the optional part). Clearly, we should try to keep
their number as small as possible, e.g. only one for math, only one
for physics, only one for chemistry, etc., but trying to squeeze
everything in a single core font might lead to solutions that might
compromise the usability in some fields.

Ideally, one would need only one of these core fonts in a document,
e.g. a math journal would use the math version and a physics journal
would use the physics version (in whatever typeface and shape they
see fit). I must admit, however, that the situation is somewhat
more complex in chemistry, which is due to the special meaning of
the \fontdimens of \fam2. (Too bad that there is only one \fam2!)
Thus, the two different versions needed in chemistry should not be
too different in their encoding, e.g. the version used for chemical
symbols might simply leave out greek, if it is not needed, but it
shouldn't introduce any additional characters that conflict with
the other version and cause trouble to the macro packages.

The METAFONT CM version of this variety of math core fonts could
be produced using a single source file, containing the programs for
all characters needed in the different versions, but they would be
generated only on demand, if a code for the character was specified
in the driver file. Different MF driver files (with different font
names!) would then specify the encoding. (This is what J"org called
an atomic encoding with real fonts.) The PostScript versions of
these core fonts would simply follow the encoding of one driver
files or another. Clearly, I didn't mean that everyone should
be free to generate arbitrary versions of the core fonts with
different encodings under the same name! Thus this approach
should not cause any nightmares of the kind Barbara mentioned.

In the end we may end of with a couple of math core fonts, e.g.
MCM for mathematicians, MCP for physicist, MCC for chemists,
just as we have DC, FC and some variants of DC for Welsh and
for Baltic languages, etc. They would all have a lot in common
and an atomic encoding might be used to generate all of them
from a single source using different driver files that specify
what's different in them.

I hope this clarifies the situation...

Ulrik Vieth.