`limitations' of OzTeX (was: fontinst with 8y.etx)

[Melissa O'Neill]

Late to the discussion, I see people are talking about `Melissa's Mac
mods', but I'm not sure whether people are talking about my providing
`MacLY1.enc' for OzTeX users, or the fact that I use a custom encoding
that isn't LY1 or 8r in a vain attempt to skirt around bugs in the
Macintosh Acrobat reader.  I'm going to assume the former (but perhaps
other people are confused too, and the discussion has really been at
crossed purposes).

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

Can you elaborate what you're envisaging here?

... Berthold K.P. Horn replied (clearly talking about MacLY1.enc):
>> 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
>> has to be done to approximate lslash, ff, eth, thorn etc.

... to which Rowland replied (apparently talking about OzTeX)
> This is not a limitation of Macs, but a limitation of some software
> on Macs.

OzTeX and some of the Windows DVI previewers faced the same problem --
their authors aren't/weren't prepared to (or weren't able to) figure
out how to get ATM and/or the operating system to reencode fonts.

OzTeX takes the attitude that it'll attempt to reencode fonts itself,
and uses a supplied mapping to go from 8r or LY1 to MacRoman, thus it
does the reencodding rather than the OS. The mapping is imperfect because
some glyphs don't exist in MacRoman but usually acceptable.

The equivalent Windows programs apparently considered this approach too
much trouble (or perhaps never thought of it) and so instead require
that users work within the Windows ANSI encoding, or use non-standard
fonts like Computer Modern. Because of their `solution' to the problem,
both 8r and LY1 were designed to be as close as possible to Windows ANSI
in an attempt to appease these encoding-challenged Windows programs.

I prefer the OzTeX solution, even if it does mean that when you design a
new encoding you need to come up with a mapping file to map that encoding
to MacRoman.

    Melissa.

P.S. My own custom encodings, which are based on the PDFDocEncoding
wouldn't work particulally well on these Windows DVI previewers. If we
rate an encoding's compatibility with Windows ANSI as N+M, where N is
the number of slot clashes, and M is the number of glyphs that map to
empty slots in Windows ANSI (and thus lower numbers are better), we get:

	TeXBase1Encoding (aka 8r):	 4+21
	TeXnANSIEncoding (aka LY1/8y):	 7+35
	PDFDocEncoding:			23+16
	my current custom encoding:	28+26
	ECEncoding (roughly T1):	63+41

Thus we can see that 8r is most conciliatory towards these Windows
programs.