Comments wanted: Directory structure of fontinst/inputs/
Vladimir Volovich
vvv@vvv.vsu.ru
Tue, 5 Sep 2000 12:11:45 -0400
"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.