fontinst with 8y.etx

[Hilmar Schlegel]

Ulrik Vieth wrote:
> Hilmar Schlegel wrote:
> >> > BTW, if LY1 is functionnally equivalent to 8r, why 8r ?
> > No, there is a an essential difference: LY claims to be Acrobat-Reader
> > proof when making PDF. If that works in any case, esp. on a Mac is not
...
>  don't bother much about this because I have no problems with VF.
> I just was saying that if you build virtual T1 and OT1 on top of 8y,
> you can you have all in one run, and you can use whatever you prefer.

The idea is fine but not that new and there are a few traps to realize
the "easy" approach.

> > 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. Also due to different checksums it is

One more clarification to rounding: the Y&Y TFMs are one thing and the
actual metric data utilized in the calculation of VF another. Therefore
interpreting the VFs potentially leads to an overhead if the small
rounded-away differences are compensated for. In short the actual Y&Y
TFM used for positioning is different from what is coded in the VF and
Tex thinks it is.

> > not straight forward to mix "raw" fonts from Y&Y and VFs made by
> > fontinst.
> 
> I realize that rounding is indeed the problem, but there's little you
> can do about it.  

You can either rewrite fontinst to use floating point metrics instead of
AFM-unit integers or use "raw" TFMs generated by fontinst with exactly
identical rounded data. There is no real precision loss since
differences are below 1 AFM unit (1/1000 em) except for CM fonts which
use advance width of non-integer dimensions.

> OTOH, my 8y.etx does put in a little more than just
> straight converting and reencoding of the AFM metrics.  For instance,
> I can easily put in all the TeX input ligatures, which you find in 8r,
> such as `` and '' for quotedblleft and quotedblright, etc.

Exactly this makes them different from the Y&Y TFMs: they use a specific
set of ligatures and can provide special generated kerns. Furthermore
they can contain ligatures from ligature instructions of the AFM file,
though they miss ligatures going beyond that simple AFM scheme whereas
Tex's ligatures coded by fontinst can be more general.

> >> 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?  WDYT?
> 
> > From the Tex view it is completely irrelevant which
> > all-Standard-Roman-Character-Set encoding is used. For the purpose
> > in question it is however necessary or at least of desire to add a
> > few things to LY1 to make complete T1 fonts from fonts which provide
> > some additional characters. This applies especially to Eng and A,
> > E-ogonek which are usually not provided as composites. Postscript
> > level 3 fonts will provide them.
> 
> How many or how few fonts do provide these characters?  If you use 8y
> as a basis for virtual fonts you can fake them in T1 as usual with 8r,
> if you just rely on reencoding, you can't.

All new Microsoft "big" WGL fonts provide a generalized set of
characters. The entire Adobe PS level 3 library will provide these. 
Hm? How do you think you can "fake" Eng and eng? Why to use a bad
composed A-ogonek when the font provides the bonafide character?
Well, yes if your viewpoint is that these are "irrelevant" why are they
in the T1-encoding then?
You can always work with an "Ersatz" if you like...

> > If one keeps the little details in mind LY1+ works just fine.
> 
> At least, it's as good or as bad as using 8r.  Whether it's better
> remains to be seen.

LY-encoding works fine with PDF - Y&Y TFMs are difficult to use with
fontinst due to the rounding problem and it is much easier to generate a
consistent set of TFMs by fontinst. For "raw" font application you can
choose either way depending on convenience or special features.

Hilmar Schlegel

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