[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `limitations' of OzTeX (was: fontinst with 8y.etx)
- To: "Melissa O'Neill" <oneill@cs.sfu.ca>, fontinst@cogs.susx.ac.uk (Fontinst), tex-fonts@math.utah.edu (TeX Fonts), pdftex@tug.org
- Subject: Re: `limitations' of OzTeX (was: fontinst with 8y.etx)
- From: Rebecca and Rowland <rebecca@astrid.u-net.com>
- Date: Sat, 13 Jun 1998 23:44:36 +0100
- In-Reply-To: <199806131927.MAA25135@daisy.cs.sfu.ca>
- References: <l03130303b1a78711eed4@[194.119.133.30]> from "Rebecca andRowland" at Jun 13, 98 02:47:45 am
At 12:27 pm -0700 13/6/98, Melissa O'Neill wrote:
[snip]
>... 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)
More-or-less.
>> 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:
[snip]
> 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
Rowland.