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

Rebecca and Rowland rebecca@astrid.u-net.com
Sat, 13 Jun 1998 23:44:36 +0100

At 12:27 pm -0700 13/6/98, Melissa O'Neill wrote:
>... 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.

This is what OzTeX's QuickDraw dvi driver does; you can't get proper
re-encoding on screen or printing to a non-PS device.  If you're using one
of OzTeX's built-in PS dvi drivers (dvips, for example), you *do* get
proper re-encoding.

>From my count, in 8r encoding, there are 22 glyphs that OzTeX re-maps to
approximations of the real thing, and three glyphs that are dropped
altogether (1/4, 1/2, and 3/4).

Given that 8r encoding was designed to be nice to Windows TeX systems,
OzTeX's approach gives results that compare favourably with 8r under
Windows ANSI encoding:

> 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