Comments wanted: AGL, Unicode, T1 vs. CE/Baltic
Tue, 5 Sep 2000 11:47:06 -0400
At 12.44 +0200 2000-09-05, Hilmar Schlegel wrote:
>The really bad thing is that I do not see how to fix the clash of two
>characters for one slot (actually 4 characters in two slots because of
>- remove T/t-commaaccent and use the slot(s) for something else (e.g.
>the Turkish lowercase Idotaccent = dotlessidot, Turkish uppercase
>dotlessi = Dotlessi, which would be necessary to make hyphenation
>- make room at another slot for S/s-cedilla: e.g. remove Y/y-diearesis
>(the problem would be again that the affected hyphenation patterns---if
>there are any---would have to learn about the new/alternative position)
>- introduce a slot for commaaccent to support at least the construction
>of Baltic characters;
If these characters are used in Romanian and Turkish, then why do you refer
to them as Baltic characters?
One could put the comma accent (and its upside-down form) in some slot in
the TS1 encoding. This would be sufficient for use by the \accent primitive
(and various \ialign constructions).
> if this accent is not available I see no alternative to making
>S/s-cedilla a "constructed-only" character, i.e. remove it from
>T1-encoding and access it always via a Tex accent primitive.
Do you mean S/s-comma? I cannot see why S/s-cedilla would have to be removed.
>Then there would be a compromize possible: all C/consonant-commaaccent
>characters are accessed via a ligature C/consonant+ogonek.
What??! T1 has no room for any more glyphs, so how could using ligatures
>work with standard T1-encoding and T/S-commaaccent and as well with an
>adopted Baltic variant (e.g. Turkish characters replaced by g, k, l, n,
>r-commaaccent, Baltic hyphenation patterns should know about this).
>There are only V/vowel-ogonek combinations in existance which require
>the bonafide ogonek accent.
>The advantage of this approach would be to cope consistently with all
>the commaaccent characters *without* the introduction of a new accent in
>the Tex/Latex scheme and asuring a high degree of compatibility on the
It all sounds terribly complicated (and error-prone) to me. Wouldn't it be
better to start working on a T1A (or whatever) encoding to support the
needs of the languages that are partly left out in the cold by T1?