T1 (was Re: Comments wanted: Directory structure of fontinst/inputs/)

[Hilmar Schlegel]

Primoz Peterlin wrote:
> 
> On Tue, 5 Sep 2000, Hilmar Schlegel wrote:
> 
> > > This is a well-known issue. Romanian delegates weren't careful enough when
> > > the ISO 8859-2 standard was in preparation, so cedilla slipped in place of
> > > comma below,
> > It is no problem to use the correct characters in IsoLatin2-encoding!
> 
> Well, depends on how you look at it. If you are adhering strictly to the
> standard, ISO 8859-2 is not suitable neither for Romanian nor for Turkish.

There are of course always two ways to see it: character set definitions
for text source exchange and a graphical definition of what gets
printed.
As long as you agree on one text encoding on both ends of a transmission
it is more or less unimportant if you use a "wrong" ISO 8859-2 or
Unicode transfer encoding. The essential point is to provide together
with the text also the actually used definition of the codes.
But we want to print something. This means you can name the characters
as you like. With two font encodings using the same name for different
characters one can then cope as long as there are fonts providing the
desired outline.
Fonts utilized for professional printing do so for years - Tex did not
and this didn't change with "new" text encodings ("European" means in
this context restricted European).

> I believe this was also the rationale for ISO 8859-16 (Latin 10) proposal
> <http://www.egt.ie/standards/iso8859/cd8859-16-en.pdf>.

If you would wait for standards you could presently not use any of the
characters in question since M$-win WGL4 fonts don't provide them, you
would still have to stay with the "Unicode codepage 2" work with
"CEDILLA BELOW" &c.

I.e. standard is not what ISO has written down but how people can
despite the faults achieve a correct printout.

> > > ... T with cedilla was retained in the
> > > ISO10646 standard on 0x0162/0x0163, although it is to my knowledge used in
> > > no language.
> > Correct: there is no such character. Unicode & AGL are fixed.
> 
> This must have been corrected in Unicode 3.0.1 then. In 3.0 it was still
> there (page 350 in the book).

There is no such character to be used in print. Due to
backwards-compatibility the Unicode value holds still the verbal
description, "unicode codepage 2" fonts still have the character there
which would show up in applications using this code for internal
representation of Romanian text (again it is not important which code to
use internally but what really gets printed since we are talking about
fonts, not markup).

> But this discussion is actually straying away from the issue of TeX font
> encoding and fontinst, right?

Of course yes. However the aspects regarding T1-encoding are relevant
and perhaps fontinst is the best place to aid users in their practical
needs (since I don't believe that the default fonts will be fixed).

Best regards,
Hilmar Schlegel
###