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

[Hilmar Schlegel <hshlgaii@mailszrz.zrz.tu-berlin.de>]

Melissa O'Neill wrote:
> 
> 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
...
> Thierry Bouche wrote:
> >>> For instance: is there a way to combine LY1 & Melissa's Mac mods?
> Can you elaborate what you're envisaging here?

Making LY1 PDF-reader proof, even on a Mac if possible...

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

You can always install fonts which provide the full set of characters
for Tex...

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

"some" and "usually" are not a category of much relevance here: complete
and exact is the key for a reliable solution. It is certainly the wrong
end to have limitations from within Tex implied by the previewer used
;-)

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

It was already explained that neither MS-win UGL nor MacRoman encoding
can provide a complete Tex character set - therefore the suggestion to
use for example LY to map virtual fonts on.

> 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 idea is not to have a "degree of incompleteness" but a working
solution...
Certainly one should keep a clear distinction of the schemes to
rearrange character codes via xchr/xord, reencoding fonts, mapping on
several fonts by VFs. 
In case a certain Tex-previewer only permits to preview English text
then users must decide if that is sufficient for their purpose.
Since the discussion has the target to produce reliable (with respect to
Acrobat bugs) and complete PDF files the deficiencies of the individual
platforms and especially the previewers is completely irrelevant here.
(PDF provides all available characters on all platforms...)

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

It is not the question which system Tex is running on but the optimal
way for making Tex output a fine cross-platform communication format.

Hilmar Schlegel

-- 
---------------------------------------------------------------
mailto:hshlgaii@mailszrz.zrz.TU-Berlin.DE?Subject=Mail response
---------------------------------------------------------------