fontinst with 8y.etx
Fri, 12 Jun 1998 15:21:54 +0100
Berthold K.P. Horn writes:
> LY1 has the feature that it works around known encoding sensitive
> bugs, except the ones in the Macintosh Acrobat Reader. And no
> encoding appears to be able to do that. This is not
> to say there aren't bugs in other Acrobat Readers or in Distiller...
Since you agree that Macintoshes live in a special encoding hell of
their own, I never saw why 8y is better than 8r in this respect. I
can't think when I last had an encoding problem, and of course I use
8r every day
All other things being equal, I'd happily switch to using 8y as a
plug-in replacement for 8r. But they are not equal - there are
thousands and thousands of people out there whose work revolves around
8r. Ok, they don't *know* thatt, but they wont take kindly to being told
that tens of megabytes of files on CTAN are about to change, and that
distributions from OzTeX to teTeX are all going to change incompatibly
I leave aside the fact that the best-selling LaTeX book of the last
year has a detailed description of 8r in it....
Possibly not everyone reading this realizes *quite* how much hate mail
one can get when one tinkers with something like PS font metrics for
But I stress that I have nothing against 8y. I just remain to be
convinced that the pain of changing will be outweighed by the
> Adobe Type Library alone that do not have Berry names. Also,
> may be it is time to make a new start and use something more
> sensible, like PS FontName, or better the 5+3+3+... contracted
> PS FontName.
Unless you simply utilize a lookup table, one point of the Berry
scheme is to be able to reconstruct family details from just the
name. It forces you to decide whether NiceFontMedium or
NiceFontSemiBold maps to LaTeX's "bx". Long names don't help you there.