At 21.37 +0100 2004-01-16, Vladimir Volovich wrote:
>Lars,
>
>thank you for your comments. Let me ask your opinion on the practical
>question which was the source of my initial inquiry.
>
>The question is: if you were designing a new[1] LaTeX2e encoding
>definition file for some font encoding which contained all Latin
>letters and the ring accent, BUT NOT the Aring letter, would you put
>the special definition of \DeclareTextCompositeCommand for the
>combination "\r A" which is the same as the one present in ot1enc.def,
>or you would rather remove it, and let the "\r A" be constructed like
>other accented letters?

I would probably drop that special definition. It introduces some rather
odd extra conditions on the font, without giving anything in return for the
indended target audience.

>E.g. the cyrillic T2* font encodings contain
>the Latin latters and the ring accent, and e.g. t2aenc.def contains
>the same \DeclareTextCompositeCommand as in ot1enc.def. Was is the
>right thing to do to put this composite command into the encoding
>definition files?

Probably not...

>This question should be considered having in mind that the default
>font family would be Computer Modern, but that it should NOT be
>concentrated only on the CM family, but try to "do the best thing" for
>other font families which might be used with this font encoding.[2]

>[2] that means that the gap between A and ring in \r{A} will be
>smaller than the gap between other accents and other letters. would
>THAT be acceptable?

I don't think the "size of the gap" is a relevant parameter here. My
impression is rather that accents sit on an axis---the exact position of
which has to depend on the height of the base character, but we can ignore
that here since capitals are fairly even---and it is the position of this
axis that needs to be consistent. I furthermore feel that some accents
(dieresis, dotaccent, ring) should be centered on this axis, whereas others
(accute, grave) are better off with the lower end on the axis. Since the
ring is larger than the dotaccent, this makes it necessary that the gap
between ring and letter is smaller than that between a dotaccent and the
letter.

But of course the gap must not be smaller than the negative of the line
width of the ring (meaning: if the A sticks up inside the ring, then the
ring is too low). This is probably the only placement that is absolutely
wrong.

>Would your answer differ if there was no compatibility issue with CM
>font family? i.e. if there were no CM-like fonts for that font
>encoding, and only "arbiotrary" font families would be used?

No. I wouldn't require a <some-new-encoding> member of the CM family to
follow the OT1 behaviour in that respect.

[snip]
> LH> This might actually be the reason to _make_ it touch the
> LH> A. Recall that accents over capitals are usually quite close to
> LH> the letter (closer than in the case of lower case letters).
>
>i meant that the \accent command places accents using the same "gap"
>for uppercase and lowercase letters (is this so?); so i was asking,
>are you proposing that commands like \" \' \` shall be redefined to
>behave differently if they are applied to capital letters, i.e.use
>some trick similar to the one used in the definition of \AA in plain
>TeX or \r{A} composite command, to make the gap smaller.

Aha. I was rather thinking about what a font designer would do.

Actually, as a general rule I would think that _if_ the author of a new
font encoding includes some trick like the

\DeclareTextCompositeCommand{\r}{OT1}{A}
   {\leavevmode\setbox\z@\hbox{h}\dimen@\ht\z@\advance\dimen@-1ex%
    \rlap{\raise.67\dimen@\hbox{\char23}}A}

of OT1, then he should design this trick so that it can work for arbitrary
font designs. The only way to accomplish that is probably to store the
vertical distance by which the ring should be adjusted in a \fontdimen, but
that is fine. It is anyway the responsibility of the encoding author to
define the fontdimens (beyond those which are hardwired into TeX) and the
only practical bound on the number of fontdimens in a font is the bound on
the total size of the TFM file.

Lars Hellström