W3C home > Mailing lists > Public > w3c-math-erb@w3.org > June 1996

Re: font-change operators

From: Bruce Smith <bruce@wolfram.com>
Date: Sun, 2 Jun 1996 15:29:23 -0700
Message-Id: <v02130503add7beff7a26@[140.177.115.10]>
To: Ron Whitney <RFW@math.ams.org>
Cc: w3c-math-erb@w3.org
>2. I think there are many font calls in math which are most naturally
>expressed as (say) prefix operators, and not in the normal HTML method.
>It may be that distinguished methods would lead to confusion, although
>I'll mention that AMSTeX and AMSLaTeX distinguish between "textual"
>font changes and math font changes, and users seem to have accommodated
>themselves to this.  Font calls as operators also accord more with
>their function as "embellishments", as an accent might be regarded
>(so that "&tilde; f" and "&bold; f" remain parallel).

A prefix operator for changing the font of the following identifier
seems possible in principle -- it could make use of the transformation
rule mechanism, provided the structure introduced on the right-hand side
of a rule can contain ordinary HTML (but which can be interpreted by the
math code, since the parent browser of a plugin will never see the right-
hand sides of these rules, unless this transformation rule mechanism is
built into HTML as a whole).

I agree with you that this is often a natural way of thinking about
a font-change.

Do you have a good sense of the number of such operations that are
desirable, and the parameter domains needed for each one?

I take it that the distinction in AMSTeX and AMSLaTeX between
"textual" font changes and math font changes was made
because it was technically necessary, and not because it was
a desirable feature -- is this right? I think that this would
not be needed if the text was being handled by the same code,
though on the other hand, a prefix operator for changing the font
of the next identifier or expression might not seem as convenient
for use with text as a surrounding wrapper, so both methods would
be desirable. If I'm wrong and this distinction is a desirable
feature in the first place, it should certainly also be possible
to make it work that way.
Received on Sunday, 2 June 1996 18:25:16 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:57 UTC