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

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

Berthold Horn wrote:
> At 10:29 PM 6/13/98 -0400, Hilmar Schlegel wrote:
> >Making LY1 PDF-reader proof, even on a Mac if possible...
> MON:>> 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 ?

Depends what the target is - use the fonts or play games with incomplete
character sets...

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

Well, a little detail is that "MAP" instructions in VFs cover mapping
onto different fonts - the central point of the discussion to find a
possible way to have a complete Tex character set on one hand side and
to make the best out of the lousy GUI on the various "windows" systems.
The open problem is if Acrobat search facilities are robust enough to
work accross platforms with different interpretations what a "text" font

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

You must do reencoding in either way to satisfy Tex's needs - or you
degrade Tex down to the level of what contemporary primitive GUIs
The advantage of PDF is that it provides the full spectrum what Tex
covers without  compromizes due to platform limitations. The hope would
be to work around of existing bugs in this approach - possibly by using
(one or more) encodings which are functional on all platforms. The
question was if LY is such a candidate.

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

OT1, T1, OML, OMS, OMX with relevant variants and additions, i.e. what
Tex needs for being "complete" ;-) You mention character code
definitions for information transfer not fonts for printing.

Hilmar Schlegel

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