fontinst with 8y.etx

[Berthold K.P. Horn]

Hi:

At 04:11 PM 98/06/11 +0200, Thierry Bouche wrote:

>The question is: why did we choose 8r rather than something else. 
>The main question at the time i write seems to be: is there an
>encoding that could insure portability of PDF files across platforms
>(including Windows & Macs...) that would be functionnally equivalent
>to 8r (i.e. making visible all adobe 228 glyphs + ff-ligs when
>available). 

8r was chosen before problems with Acrobat were known.

PDFEncoding is another possibility, except that it does not provide
access to ff-ligatures and dotlessj, fraction, sfthyphen, nbspace...

And it has grave accent where we want quoteleft, and it has quotesingle
were we want quoteright.   I believe there is a general
abhorence of using active characters to work around that problem.
Also I don't think it works reliably in the Mac Acrobat Reader either.
Plus, a lot of work has gone into 8y...

>For instance: is there a way to combine LY1 & Melissa's Mac mods?

AFAIK, Mellisa's `mods' are simply work-arounds for the limitations
of Mac: problems due to not being able to access 21 of the 228 glyphs
on the Mac (due to lack of ability to reencode fonts - somthing not
fixed by VF, I hasten to add, because VF only `remaps').  So something
has to be done to approximate lslash, ff, eth, thorn etc.

>Well, does there exist something working proprely on unices, macoses &
>windowses95-99/Nt? 
>Doesn't that whole question seem surrealistic to you, talking of some
>_portable_ doc format???!!

Well, I gather that some people on Unix are using LY1, as are some
OzTeX users...

>» On the other side it is promoted with the argument to avoid the need of
>» VF - which is only important for Dvi-interpreters not capable of doing
>» VF and not relevant in the context of fontinst. 

>This is also the reason for fontinst making ligfull 8r TFMs. That was
>a request from a Mac user, as far as i remember.

I am not sure you can dismiss this so easily, particularly in the
context of PDF.  For example, if you make a nice virtual text font
based on CM you will end up with all the same problems in PDF
as you do with the original CM, since the virtual font does not
exist in the PDF domain.  You can't search, for example, bookmarks
come out wrong, etc.

>» > Since hardly anybody seems to be interested in typesetting directly
>» > with 8r, while OTOH Y&Y does promote typesetting with 8y (regardless
>» > whether or not you may find that adequate for non-expertized fonts),

>» Well, there is the difficulty that fontinst generated LY encoded TFMs
>» are quite different from those made by the Y&Y tools. This leads under
>» certain circumstances to a big processing overhead due to the fact that
>» fontinst is rounding metric data to a grid of 1 AFM unit while the Y&Y
>» tools do not round metric data. 

Not sure what that refers to.  Only CM and EM fonts use `non-rounded'
numbers.  As for overhead, it took a few minutes to do all 2300
fonts in the Adobe library, while I have heard R&R estimate 5min
to 30min per font using fontinst...

>but y&y doesn't put its ton of LY1 TFMs on CTAN, and they don't
>conform to karl berry names? 

You can happily take the TFM files now on the Y&Y web site and port
them to CTAN.  As for Karl Berry names: more than half of those fonts
don't have Berry names (and this is just the Adobe Type Library),
and in some cases it wasn't clear what some fonts were called. So it
was easier to organize the files on the names given by Adobe.  
It would be easy to extract those that have Berry names and rename
them, given that the HTML table has both names (and more) listed.
But what do you do with the rest?

Since few people are now stuck on 8+3 platforms, maybe it is time to
forget this.  We could use PS FontName as the TFM file name,
or, since those can get rather long, use the Mac 5+3+3+...
contracted names, which are unique also (or supposed to be anyway
- for otherwise the font cannot be used on the Mac).

>» Also due to different checksums it is
>» not straight forward to mix "raw" fonts from Y&Y and VFs made by
>» fontinst.

>this is indeed a problem, meaning that y&y LY1 TFMs could be of some
>use to other users, but fontinst's TFMs could'nt be used with an y&y
>system? 

You just turn off the encoding warnings in either case.  It is a pity
though not to agree on a sensible checksum algorithm :-), like
the mod 40 method to hide the font encoding.

>» > using fontinst to install 7t/8t/8c on top of 8y (and 8x, if available)
>» > might turn out a compromise that could make eveyone happy?  

Regards, Berthold.

Berthold K.P. Horn
Cambridge, MA		mailto:bkph@ai.mit.edu