The 8r strategy (Was: Unsubscribe)

[Arthur Ogawa <Ogawa@teleport.com>]

Sebastian Rahtz wrote:
>...how
> about putting [in] the perspective of your customers and your drivers?

PTI now bundles dvips with their product, FYI. 

But I'll take Sebastian's suggestion to PTI's tech support to heart on
behalf of Textures users instead.

In the wake of the recent flap over the 8r encoding support for
psnfss-class fonts, I understand, possibly inaccurately, that Sebastian,
in a recent change to his fontinst work had inadvertently lost ligatures
entirely. I expect that he has reinstalled or will reinstall those
ligatures.

Please correct me if I err?

But Constantine Kahn raised an issue that's very crucial to Textures
users, who depend entirely on his 8r encoding file, namely whether or
not the use of such an encoding is and will be supported by the
developers of the psnfss font metrics and others who might post metrics
based on Sebastian's fontinst work.

I'd like to know for the sake of future planning WRT Textures, 

1. Whether users of Texture can depend on continuing to use
Constantine's 8r encoding work in the form of his 8r.mtx, that is, will
psnfss metrics and their like continue to be compatible with 8r.mtx?

2. Who else uses the 8r-fonts approach? Dvips? Dvipsone?

And purely for my own edification:

3. What means do dvips users employ that avoids their use of 8r.mtx? Is
it the TeXBase1Encoding.pro file? 

4. More generally: it appears that the 8r-fonts work represents a
bifurcation point. I'm trying to understand the implications of this
bifurcation, which apps go to which side, and what methods are used
along each path.

I appreciate your help in understanding these points. If there exists
any documentation of same, please point me at it.

TIA.

-- 
Arthur Ogawa/TeX Consultants
voice: +1 209 561-4585 Fax: +1 209 561-4584
mailto:ogawa@teleport.com
http://www.teleport.com/~ogawa
ftp://ftp.teleport.com/users/ogawa
PGP key: finger -l ogawa@teleport.com