fontinst with 8y.etx
Hilmar Schlegel <email@example.com>
Fri, 12 Jun 1998 15:22:52 -0400
Berthold K.P. Horn wrote:
> 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
> 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
- 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
> >» 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'
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.