fontinst with 8y.etx

[Hilmar Schlegel]

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 think so.

> (i.e. making visible all adobe 228 glyphs + ff-ligs when
> available).

That's not the optimal solution with T1-encoding in mind - this would
however be sufficient for most cases of course.

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

No idea what happens on a Mac.

> Concernant « Re: fontinst with 8y.etx », Hilmar Schlegel écrit : «

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

To have standard fonts without VF in case there is really no ned for
them is a fine idea - only the resulting compromizes on the side of Tex
must be taken into account.
I don't see much use of only changing the text fonts and no practical
way to change math fonts without VF - that simple.
I think on the other hand side it would be no serious bad effect if
there would be a practicable way to build the more sophisticated VF's by
mapping onto ligful (and kernful) "raw" fonts to make people happy. The
more serious argument than using fonts without VF is that PDF is better
supported by LY.

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

The names can simply be changed in case of need...
Indeed Y&Y put a lot of work into making this encoding work (from care
about hyphenation patterns, Latex macros to install them, check against
PDF software, provide *support* for this scheme &c) and it would be fine
to either use it or adjust a bit if necessary.
 
> » 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?

No, the other way round: you can use fontinst-only stuff but the
pre-made TFMs cannot simply be wheeled in by a "copy" since the metric
data isn't rounded and doen't correspond consequently to what fontinst
uses to calculate the data in the VFs. Possibly one could try to feed
LY1 TFM -> PL into fontinst and hope the best - it is however not
*exact* and might confuse the dvi-drivers. Even if fonts which aren't
scaled are not affected (we started from integer AFM-units anyway) it
becomes a problem as soon as fonts are scaled.

> » If one keeps the little details in mind LY1+ works just fine.

> that is: as fine as 8r?

No, it has not the PDF-Reader problems...
I.e. LY1 is as good as 8r for Tex but more reliable if PDF is the
target, with the side effect to make people happy who exchange some fuzz
for dropping VF support.
I'd prefer a change to make the "raw" encoding PDF-proof for all
platforms & versions to the ability to work without VF - if there would
be such a choice (probably one can have both;-)

Hilmar Schlegel

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