fontinst with 8y.etx

[Melissa O'Neill]

Berthold K.P. Horn writes:
> PDFEncoding is another possibility, except that it does not provide
> access to ff-ligatures and dotlessj, fraction, sfthyphen, nbspace...

Also, my understanding was that sfthyphen and nbspace were characters
in the Windows(tm) character set, rather than real characters in actual
fonts. Certainly they aren't in Adobe's fonts, nor in PS fonts designed
specifically with TeX in mind like LucidaBright. (BTW, `fraction' is in
the PDFDocEncoding, since it is one of standard 228 glyphs in Adobe text
fonts).

The `ff', `ffi' and `ffl' ligatures are typically found in expert fonts.
Fonts like LucidaBright are the exception, rather than the rule.

More to the point, if you aren't going to have an encoding just to the
standard 228 glyphs in a PostScript font, which extra ones do you add.
I currently set text in my own custom encoding which I call PDF+, which
adds

  dotlessj onefitted colonmonetary rupiah figuredash threequartersemdash
  ffi ffl ff onedotenleader twodotenleader onethird twothirds

to the standard 228, but other people might wish to make different
choices. And there are plenty of extra glyphs to choose from -- Adobe
Courier contains 260 glyphs, the extra ones being:

  Gcaron IJ Idot LL Scedilla arrowboth arrowdown arrowleft arrowright
  arrowup center dectab down format gcaron graybox ij indent largebullet
  left lira ll merge notegraphic overscore prescription return scedilla
  square stop tab up.

So it becomes very easy to show that it's just not possible to have an
encoding that covers every glyph in every slightly non-standard text
font.

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

This positioning is certainly annoying, but is a problem only if you're
typesetting directly in the font. If you're using a VFs and using
something like the T1 encoding in TeX, there is no problem.

The problem I have with LY1 is that it wastes valuable space in the
encoding by including duplicates, and omits some glyphs I'd like to have
access to.  It also doesn't work well with all Acrobat Readers (perhaps
no encoding does, but since it is often promoted on the idea that it
works around Acrobat bugs, it's important to realize the falsity of any
such claims).

Thierry Bouche had written:
>> 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). 

This question remains to be answered. I don't think that the PDFDocEncoding
is the solution necessarily, but it is conceivable that it might be a
better starting point than LY1.

Regards,

    Melissa.