fontinst with 8y.etx

[Hilmar Schlegel]

Berthold K.P. Horn wrote:
> 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...

It depends certainly which function "functionnally equivalent" means:
- standard 228-set
- usable in the context of existing hyphenation characters
- plausible for PDF-search (platform-dependent)
- usable for direct use of "raw" fonts
- covering the maximal number of Cork character code in addition to the
228
- workaround of Acrobat reader bugs

I don't think you can find one *single* encoding covering all that.

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

Hm, VF not "only" remaps but maps on different given system fonts as
well allow to use one encoding within Tex conforming to existing
hyphenation patterns while providing a PDF encoded to be searchable to a
certain extent (one could consider this as an advantage ;-)

> has to be done to approximate lslash, ff, eth, thorn etc.

PDF at least is not restricted by this - a file can contain characters
even not accessible for entering into the search box on the platform in
question...

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

One could map CM onto fine text EM fonts to overcome this for people who
prefer the CM style for typesetting ;-)
Tex sees only OT1 while the PDF has some searchable encoding - virtual
OT1 has gone then, right.

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

fontinst is rounding to integer AFM units - scaling fonts and/or CM/EM
non-integer metrics introduces differences well resolved by dvi-units.
PS files can become triple size and only distiller gets back to normal
due to cutting off the noise.

> >but y&y doesn't put its ton of LY1 TFMs on CTAN, and they don't
> >conform to karl berry names?
> 
> 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?

Use numbers? ;-)

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

Uggh! Do we forget case also?

> >» Also due to different checksums it is
> >» not straight forward to mix "raw" fonts from Y&Y and VFs made by
> >» fontinst.
> 
> You just turn off the encoding warnings in either case.  It is a pity

That's certainly not the intention... 

> though not to agree on a sensible checksum algorithm :-), like

Fine would be *one* unique checksum in a scheme which *is* supported by
the software dealing with the fonts ;-)

> the mod 40 method to hide the font encoding.

Also the family code is handy place.

Hilmar Schlegel

-- 
---------------------------------------------------------------
mailto:hshlgaii@mailszrz.zrz.TU-Berlin.DE?Subject=Mail response
---------------------------------------------------------------