[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cyrillic in math

> i might think your argument has substance if you can show me *any*
> way of getting a bold upright gamma. 
> 
> if i get what i need when i type \bf G or \bf g or \bf \Gamma,
> but don't get what would be expected when i type \bf \gamma,
> i don't think this is my fault. this is like having a quarter
> of screws in a device left-handed and the rest right handed
> for no apparent reason---other than perhaps just lack of 
> (fill in your favorite reason here) on the part of its designer.
> 
> i don't think there is any value in trying to make up lame
> excuses for something that's so obviously irrational.
> if there is a way to fix it, why not do so?

I did not intend to suggest that I favored continuing the current
behavior of \bf\gamma---my opinion is quite the opposite, in fact. I
was only pointing out that user syntax such as {\rm text} has
associated problems very similar to the problem of \bf\gamma,
therefore if you don't like \bf\gamma then you should also not like
{\rm text} as a general syntax.

Also I believe you have misunderstood one point.  The \bf\gamma
problem is not so much a math font encoding problem as it is a macro
problem and user interface problem. You seem to believe that the
current proposals for the new math font encoding are designed to
perpetuate such current problems, when in fact I would say that they
are designed to make it *easier* for macro writers to eliminate such
problems, by (for example) putting the lowercase Greek and the
uppercase Greek in the same font instead of strangely split up as in
the old CM encoding.

So I would say, your dissatisfaction here merely confirms what I said
earlier, that the design of plain TeX's \rm, \bf, ... for changing the
font of math symbols is inadequate. Why shouldn't the user also be
able to type \bf\sum or \bf/ or \bf\leq (all of which fail)? The
problem is that defining \bf to be a mere \fam switch, as in current
plain TeX, absolutely *cannot* work in all cases unless you use a font
size much larger than 256 [ = max(all mathords,all nonmathords), in
fact]. Since font sizes larger than 256 are beyond the scope of the
current math encoding project, the best solution at the present time
would seem to be a macro like AMSTeX's \boldsymbol that does something
clever to select the right math family by looking at the meaning of
its argument. And this is practical only if the argument is restricted
to a single symbol, with multiple bold symbols either being done in
text mode (if they are by nature a text string) or by separate
\boldsymbol commands (if they are by nature independent elements
within the current formula).

--Michael