[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 10:29 PM 6/13/98 -0400, Hilmar Schlegel wrote:

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

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

?  Meaning they are not set up as `text' fonts ? 
   And what about the other 89,900 (:-) fonts ?
   Or are you suggesting one modify the fonts one uses ?

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

Could we agree on terminology please?  Can we call mapping numbers to
numbers (which is what OzTeX does and what VF can do) `REMAPPING'
and reserve the term `REENCODING' to assigning an encoding, which
is something that maps numbers to glyphs.  The latter being more powerful
since it can make `unencoded' glyphs accessible.  In this sense OzTeX
does remapping and does not do reencoding.  Ditto for most other
Windows or Macintosh TeX Systems.  DVIPS does reencoding, which
is easy in a PostScript only world.

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

? Most implement `remapping' as does OzTeX.  I don't think any simply
  use Windows ANSI at this stage. Y&Y TeX/DVIWindo use  true reencoding,
  so is not limited to remapping (and the loss of 15 glyphs of the 228).

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

What is a `complete TeX character set'?  WGL4? UGL? AGL? In any case,
more than 256 characters?  or do you just mean T1/Cork?

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

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

8r and 8y have one nice feature which is that they match in large part
ISO Latin 1 (better than T1 does).  Since ISO Latin 1 is a camel designed 
long ago by a committee it has numerous annoyances.  Both 8r and 8y try 
and work around these by introducing additional glyphs in the 0-31 and 
128-159 range which is not used in an ISO encoding.  Unfortunately,
in addition, in order to make TeX happy (and to keep some level of
sanity) we also have to depart from  ISO in a number of other ways, 
such as using quoteleft instead of grave accent, using quoteright instead 
of quotesingle and using hyphen instead of minus.

Regards, Berthold.