[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About atomic encoding
- To: firstname.lastname@example.org
- Subject: Re: About atomic encoding
- From: email@example.com (Alan Jeffrey)
- Date: Sat, 9 Apr 94 16:58 BST
- Cc: firstname.lastname@example.org
Actually, I don't think there's that much difference between our
goals, we just have rather different ways of going about it...
The possibilities are:
a) Have one `lowest common denominator' math core font, and put the
b) Allow the math core font to be discipline-specific.
The advantages of a) are:
* implementing fonts and macro packages is *much* simpler.
* most papers in most disciplines can be set with the math core, and
only papers requiring special glyphs need fonts with the
* most sites only need one math core font per font family (eg one CM,
one Adobe Times, etc.) rather than one per font family per
* allowing multiple discipline-specific encodings will encourage
people to produce their own encodings, and we're in danger of
getting back to the current situation, where there's almost no
agreement on math font encodings.
The advantages of b) are:
* kerning is possible between the discipline-specific glyphs and the
* one less family per math version is used.
I'm very much in favour of a), but that's probably because I'm the
person who'd have to write all the fontinst ETX code to generate the
new math fonts. (Users of fontinst have remarked on how difficult it
is to get fontinst to generate VFs with non-standard encodings. This
is not a coincidence :-)
>The PostScript versions of
>these core fonts would simply follow the encoding of one driver
>files or another.
This would only apply to the raw fonts (eg Symbol is in Symbol
encoding). The TeX fonts would use the same encoding as the CM