Re: The 8r strategy (Was: Unsubscribe)

[Constantin Kahn <kahn@math.uni-hannover.de>]

Arthur Ogawa writes:
>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?

It was a long-standing bug, and not the biggest problem with the present
psfonts release, which is why Textures users were never exposed to it. Not
by me, anyway.

>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.

The 8r *encoding* (which is all which my "8r reencoding" suitcase file
provides) was never in question; the discussion was about the present
implementation of 8r encoded fonts. Whether these fonts have ligatures or
kerns at all doesn't matter for users who use the psfonts with the vanilla
LaTeX support (i.e., in OT1 or T1 encoding via virtual fonts). A change to
ligatures/kerns in 8r fonts *will* matter for people who use these fonts
*directly*; this is most likely the case for users of TeX implementations
which don't support virtual fonts (directly). For Textures users I don't
see this as a problem. If it is the case for your customers, then you
should speak up, indeed...

>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?

Maybe you could clarify whether you are referring to (a) psfonts in their
"user-friendly" 7t/8t incarnation, or to (b) the 8r encoding itself, or to
(c) the particular ligatures and kerns in 8r.mtx?

For all I know, (a) and (b) are not supposed to change; with respect to
(c): the current release of psfonts didn't even use 8r.mtx (by mistake)
while the next one is likely to (but with a changed 8r.mtx).

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

8r.mtx is used by fontinst only, by some internal command within
\latinfamily, maybe called \installrawfont or something. I put that in
(blush), but you do not expect that I remember my own hacks, do you?
(Fortunately, Alan never documented it ;-) Nobody who wants to use
(whatever) fonts with the 8r encoding is required to use fontinst. So much
for 8r.mtx.

>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.

It's really just a discussion about the best kerns in 8r encoded fonts. For
Textures users there's likely to be a change to the metrics of 8r-fonts
with the next release (assuming that I create a new release which I didn't
promise to do!) but only with respect to kerns involving lower-case
diacritical characters.

If you care about Textures users (I trust that you do!), then you could use
whatever influence you have to convince Blue Sky Research to support the 8r
encoding, at last. As things are nowadays, it's still possible that someone
puts out his own set of (say) Chinese font encodings for Textures which
wipe out 8r just because they occupy the same internal slot (of the very
few free ones). *That's* bothering me. (Not that I would hope for anything
constructive from BS Research- I just had to deal with a person who was
told by their Tech Support that the psfonts metrics were based on TrueType
font metrics. Sigh. The thought.)

Constantin

PS: Art, note: no 'e' at the end. (But you are still doing better than my
fellow countrymen (and my bank) who try to spell my first name with a 'K'.)

--
Constantin Kahn, Am Fuhrenkampe 80, 30419 Hannover, Germany
Phone: (+49) 511-762-5380 or (+49) 511-758528 (home)
Email: kahn@math.uni-hannover.de