Comments wanted: Directory structure of fontinst/inputs/

[Hilmar Schlegel]

Vladimir Volovich wrote:
> 
> "HS" == Hilmar Schlegel writes:
> 
>  >> \galias{Tcommaaccent}{Tcedilla} \galias{tcommaaccent}{tcedilla}
>  >> %\galias{Scedilla}{Scommaaccent} % AGL 1.1 vs 1.2
>  >> %\galias{scedilla}{scommaaccent} % AGL 1.1 vs 1.2
> 
>  HS> There is no such character like Tcedilla!
> 
> surely, but nevertheless some fonts have a glyph with that name which
> usually is tcommaaccent (and that is the reason for the galias above).
> see e.g. cork.enc, EC.enc, extex.enc, tex256.enc in the dvips
> distribution (part of teTeX); unfortunately there is a huge
> duplication of *.enc files for T1 encoding in dvips/teTeX: all these
> files describe T1, but are not equivalent!!

Hm, usually the fuzz begins when the fonts actually call it tcommaaccent
despite it is some mis-shaped tcedilla or a real tcedilla. I have no
problem with the wrong name for the correct shape ;-) This is however
usually not the case for reliable fonts (CE fonts, EFO fonts, Linotype
fonts, OpenType Pro fonts and the like). There is no good reason for
using the wrong name for the correct shape. The encodings you mention
are Tex-encodings which are all more or less influenced by the faulty
definition of T1.
The essential point is what gets printed at the end: t-commaaccent with
a disconnected hook below.

Actually one would need a meta-encoding which describes the encoding
independently of the used character names in the font programs (a pk
font doesn't use any names).
The particular encoding for that specific font should be then
constructed by some intelligent software (this could well be fontinst)
to put the desired characters at the necessary code positions.

>  HS> Even given the case a font provides Tcedilla and not
>  HS> Tcommaaccent, then the character is usually wrong.
> 
> what glyph is usually "hiding" behind the tcedilla name (if it is not
> tcommaaccent)?

Typically it is t with cedilla or some sort of cut-off cedilla without
the to connecting stroke. (This is what Monotype/M$ did for their WGL4
TimesNewRoman variant ;-)
 
>  HS> LaTex defines for T1 encoding on one hand side the wrong Tcedilla
>  HS> slot which must be filled by Tcommaaccent instead and on the
>  HS> other only a single slot for Scedilla but not for Scommaaccent
>  HS> (without this you could drop also the Tcommaaccent). There was a
>  HS> fix for Unicode and AGL meanwhile but there is no real fix for
>  HS> LaTex T1 encoding!
> 
> what fix for unicode do you mean? (renaming in AGL, but what happened
> in unicode besides adding a missing glyph, or was it replaced
> incompatibly?)

In Unicode & M$ WGL4 there was the same clash of codes like in Latex T1.
(introduced by simply merging IsoLatin1 & 2)

i) adding the missing Romanian characters, separated from all other
stuff
ii) changing the description from "WITH CEDILLA BELOW" to "WITH COMMA
BELOW"
iii) moving them to a new location (required a shift in AGL which
affects Win-NT, Win2000, OpenType fonts)
 
> what glyphs are "officially" in T1 encoding (-cedilla or -commaaccent)
> currently?

No idea. 
If you put 
s-ce t-ce -> t-ce is wrong, useless
s-co t-co -> s-ce is missing (must be constructed via Tex accent)
s-ce t-co -> s-co is missing

> what are the chances of "fixing" the T1 encoding? is this question
> being discussed with the LaTeX Team?

There is no good way to really fix it: you must work-around in the best
way for your purpose. The worst case is a Romanian-Turkish dictionary
;-)
I don't think that certain fonts are to be corrected due to the little
resistance against these. I guess the minorities are clever enough to
avoid the wrong fonts instead of an obvious useless protest (perhaps
some concluded to change the system is easier than fix this).

>  >> %Germandbls SS
> 
>  HS> There is obviously no such character like an upper case ß. If you
>  HS> need for one reason or another a SS, then fake it.
> 
> i wonder, why then T1 encoding contains uppercase ß (it looks like SS). :-)
> should this be fixed too by removing SS glyph from T1?

It is for making \uppercase happy. There are better ways to achieve the
desired effect but in any case you do not need a separate character in a
font if you have virtual fonts.
Moreover has Acrobat a bug in the construction of substitution fonts
which causes wrong display as soon you use SSsmall instead of
Ssmall+Ssmall.
 
> and while we are here, one more question: iso-8859-1 contains
> ydieresis but does not contain an uppercase form: Ydieresis. Why is it
> so? Is it because the languages which are supported by iso-8859-1 and
> which need ydieresis, do not use Ydieresis?
> 
> if so, should Ydieresis be removed from T1 as well?

Y/ydieresis is not likely to be of any use since there are just two or
three words with them. It is just there for traditional reasons - there
were lengthy discussions about this on comp.fonts...

CU,

Hilmar Schlegel

###