`limitations' of OzTeX (was: fontinst with 8y.etx)
Rebecca and Rowland
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
>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