Re: Encodings, Non-T1 symbols, and bitmapped fonts...

[alanje@cogs.susx.ac.uk (Alan Jeffrey)]

Replying to some recent postings...

Mellisa said:

>It'd be nice if those on the PostScript
>side could liaise with J"org Knappen (if they aren't already) so that
>their miscellaneous symbol virtual font might have the same encoding as
>his miscellaneous symbols font for the DC fonts

This has (sort of) already happened.  The `sort of' is because I've
been bogged down with the administrivia of teaching, so I haven't had
time to look at the proposal.  It is very very very very important
that the MF and VF implementations of the TS fonts use the same
encoding---otherwise we're back in the state we were 4 years ago when
PS and MF fonts used different encodings and trying to combine them
was almost impossible.

>[Chris Rowley says that
>LaTeX2e actually can't support more than one encoding, but this seems
>to contradict my personal experience, where I've used T1 and OT1 in the
>same document, and T1 and 8r in the same document. Perhaps he can clarify
>what he means here.]

This is a `feature' of TeX.

\begin{technobabble}
   When TeX is hyphenating a paragraph, it uses the uc/lc table to
   determine what constitutes a `word'.  It is therefore important
   that the uc/lc table matches the encodings used in the para.
   Unfortunately, the uc/lc table that counts is the one in force at
   the end of the para (unlike settings to \language, \lefthyphenmin
   and \righthyphenmin, which are stored in an appropriate whatsit).
   This means that if you have some Greek in a German paragraph, that
   the Greek will be hyphenated using the German uc/lc table.  This is
   not good.  The upshot of this is that it is very difficult to
   use more than one encoding in a document (eg 8r and T1) unless they
   share a uc/lc table.
\end{technobabble}

>Finally, some points of confusuion. Alan didn't think there was a .enc
>file for 8r, yet there is one in the distribution.

Sorry, if I said .enc, I meant *enc.def.

>And to conclude, I was a little lost
>by Sebastian's "you are on your own with using 8r as an encoding", since
>it seems to directly contradict the README file in the distribution,
>which says that this is supported.

That para should go then.  The L3 team is *not* supporting 8r as
anything other than a raw font encoding for VFs to point at.

Drahoslav said:

>One often hears the phrase `despite all of its problems' about
>T1 encoding; other than not having misc. symbols (which aren't
>_letters_ anyway) *what* are the problems?

Lots of little things...  almost no fonts have a <perthousandzero>
glyph; T1 has a slot for the Sami <ng> and <Ng> glyphs but not (so I
am told) the other Sami glyphs; the Turkish letter \.\i doesn't quite
come out as expected in small caps; the inclusion of <section> but not
<paragraph>; but on the whole it's as good a compromise as we're
likely to get, and it's too late to change it now.

>If T1 is really going to be accepted
>as a standard on par with ISOLatin-x,

It isn't.  Latin-1 and -2 have the ISO sitting behind them.  T1 only
has the TeX community.

>Still, a few letters, particularly the ones which are
>not in 8r directly nor have a PCC description, look rather out
>of kilter compared to well typeset books, and could be fixed-up
>without resorting to `design sizes' or customizing for every
>font by a few (more) tweeks to latin.mtx.

Well, if you have any suggestions, mail them to
fontinst@cogs.susx.ac.uk, but there's some glyphs like <aogonek> or
<Aogonek> where there's no way to automatically place the accent---it
has to be done by hand (eg with a PCC description in the AFM file).

Yannis said:

>I would like to remind you that I'm working on UC1, UC2, UC3, UC4, UC5:
>five encodings which cover Unicode/ISO10646-1 + the necessary glyphs for
>TeX output. I would be glad if the "LaTeX2e folks" leave me the possibility
>of integrating them into LaTeX2e on Omega.

The support for encodings other than OT1 in LaTeX is getting better,
and is one of the areas we're still working on.  Our current plans are
for the LaTeX team to support OT1 and T1 directly, and to encourage
other people to look at supporting other encodings (eg Cyrillic /
Greek / IPA etc).  We want to encourage 3rd party developers to use
the font encoding commands documented in fntguide.tex and
ltoutenc.dtx---these have been pretty stable for over a year now, with
any recent changes being upwardly compatible.

As far as Omega is concerned, providing *enc.def files for the UC*
fonts is eminently sensible (my only slight worry is about the
encoding names, but that's fairly trivial).  If you want to make them
the default encoding, then you should change the format name (eg to
OmegaLaTeX) since LaTeX is distributed under the same `change the
file, change the filename' conditions as TeX.

Phew...

Alan.

-- 
Alan Jeffrey             Tel: +44 1273 678526           alanje@cogs.susx.ac.uk
School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK