Comments wanted: Directory structure of fontinst/inputs/

[Vladimir Volovich]

"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!!

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

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

what glyphs are "officially" in T1 encoding (-cedilla or -commaaccent)
currently?

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

what glyph

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

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?

"LH" == Lars Hellström writes:

 >> so feel free to include these files into fontinst. :) i'll make
 >> changes from time to time to files contained in t2 package, and
 >> they will be migrated to fontinst, ok?

 LH> Or you could put those changes directly into the new
 LH> fontinst/inputs/cyr...  (when we get it set up), which I think
 LH> would be better, actually. I see no reason why you shouldn't be
 LH> allowed to update files that you have written and maintain.

that would of course be ideal. :-)

 LH> It is an interesting approach (and I actually did something
 LH> similar---worked only in the AFM to MTX conversion---in the
 LH> ancestor for \reglyphfont), but there is a problem in connection
 LH> to the map file writer.  If the glyphs in a font have been
 LH> aliased using your mechanism and then reencoded, then the glyph
 LH> names in that reencoding will not match the glyph names in the
 LH> font, which means the encoding specified to the driver will not
 LH> use the right glyph names!

 LH> It may well be possible to get around this in some way, but it
 LH> needs to be thought about. It is probably possible to put both
 LH> the original and the aliased glyph name in the MTX in some way
 LH> (and in the same \setrawglyph command, not in two separate
 LH> commands) so that finstmsc.sty could determine what the original
 LH> glyph names were,

yes, it should be thought about; afaik, this aliasing mechanism can
affect only the .enc writer of fontinst (which appeared just
recently). other possible solutions could be:

* redefine mtx-reading commands instead of afm-to-mtx-writer so that
  the glyph description commands from mtx files would search for
  aliasing glyph names. with this we will loose useful comments in VPL
  files that some glyph taken from some font is really the aliased
  glyph (but not an incorrect name specified in AFM files)

* extend the \setrawglyph command (which is only used for ENC-writer?)
  with one more argument specifying the original glyph name. Other
  commands such as \setkern should use aliased glyph names.

 LH> but you still have the problem that you need several .enc files
 LH> for what really is the same encoding.

why? only one enc file is needed -- with glyph names corresponding to
original font (i.e. non-aliased).

 HS> It is no problem to use the correct characters in
 HS> IsoLatin2-encoding!  The problem is that T1 maps Isolatin1 plus
 HS> Isolatin2 into one encoding and leaves one single slot for
 HS> actualyl two distinct characters.

 >> although the latter form is preferred in the Romanian
 >> typography. It was later amended in the ISO10646/Unicode version
 >> 3, which includes S and T with comma below on positions
 >> 0x0218-0x021B, apart from the S with cedilla on 0x015E/0x015F. T
 >> with cedilla was retained in the ISO10646 standard on
 >> 0x0162/0x0163, although it is to my knowledge used in no language.

 HS> Correct: there is no such character. Unicode & AGL are fixed.

again, what was the fix for unicode?

	Best regards, -- Vladimir.