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

Re: Undeclared glyphs



Melissa

> 
> Sebastian Rahtz and Alan Jeffrey seem to be telling me that, as far as
> LaTeX2e folks are concerned, the `T1' encoding is "the one and only way
> to go". 
they are saying this not as an edict from on high but as a consequence
of the limitations of TeX.
  
> Perhaps this is sane, if the spirit of TeX/LaTeX is that only `often
> encountered text glyphs' are present in the main font (*), and all other
> symbols are partitioned off into a separate font. However, if this *is*
> the idea, I think that before the the final release of the psfonts
> package, someone will need to design such a virtual font with these
> characters in them -- after all, developing a raw font which includes
> all the characters available in a standard PostScript font but providing
> no way to access those characters would seem to be, well, a waste of
> effort at least. (Certainly, if I hadn't thought I could access those
> `hard to reach' glyphs with this release, I'd never have seen much reason
> to install it.)
Here you have hit on the remaning big hole in the text LaTeX fonts system:
the font encoding for a font that contains all these goodies that you
wish to access.

As Metod Kozelj said, the T1 fonts are essential to non-English
typesetting so it must remain the standard.

> 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.
I did say that this is because of a problem with TeX.  T1 and OT1 can
coexist because T1 was carefully planned to be compatible with OT1.

The problems arise when using two 8-bit encodings, both of which
contain letters, within one paragraph.  Thus the planned "text
symbols" font encoding will not be a problem but using 8r and T1 will
be.

The other, comparitively trivial problem, is that `8r' is not a good
name for a LaTeX font encoding (I suspect that the name was chosen to
show that it would not be used as one) since LaTeX will need a
file called 8r... and filenames cannot begin with non-letters on many
operating systems.  Thus the production of 8r.sty etc is a highly
anti-social act for more than one reason.

It seems like, Karl Berry does seem to think that using 8r directly *is*
okay and should be supported [to some extent, anyway]. Certainly I'm
glad that I can directly use 8r rignt now to get the characters I want.

> Finally, some points of confusuion. Alan didn't think there was a .enc
> file for 8r, yet there is one in the distribution. Also, I'm not sure
> why 8r.sty is called that, since all other encoding files in LaTeX2e
> are written <encoding>enc.def -- certainly, if one renames it to 8renc.def,
> one can then do `\usepackage[8r]{fontenc}' [although it helps to do a
> \rmfamily beforehand to cope with the \selectfont in fontenc.sty,
> otherwise it fails to realize that you've switched the default font
> family over to a PostScript font]. 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.
Such actions horrify me!

> 
> Pondering,
How we got into this sorry mess, perhaps??


chris