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

Re: About atomic encoding

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
   discipline-specific fonts.

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
   discipline-specific encodings. 

 * 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
   non-discipline-specific glyphs.

 * 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