Re: source2e reference to mthscale.sty?
Ross Moore
On 20/11/2006, at 8:26 PM, Chris Rowley wrote:
> Ross
>
> One general point.
Another first; I'm replying via the list Will setup on Google-groups,
so some of you will get this twice.
Once everyone has subscribed, we should switch to using the mailing-
list only.
>
> Whilst I appluad your noble efforts to make the maths genererated
> in the PDF `usable', would it be possible to disentangle this from the
> provision of LaTeX support (as compatible with current stuff as
> possible) for XeTeX maths?
Yes. This is (mostly) a separate thing -- I'll call it MMmap .
However, it does require knowing the macro-names that will be used
for supporting STIX math characters, as these are destined to become
the standard. In particular, there are characters in the
Lucida Arrows font (LMR encoding) that I've not found macro-names for
in any other (La)TeX reference.
>
> That does not mean that what is in xmath (as indeed all LaTeX should,
> were that possible) will not support such requirements.
Indeed MMmap is intended for (non-XeTeX) LaTeX, using pdfTeX as the
typesetting engine, since Volovich's cmap.sty isn't supported by
any other driver yet, so far as I know.
Now another issue arises.
I don't know if any of you are aware that George Grätzer is preparing
a new edition of his book "Math into LaTeX".
I don't know what you all feel about his previous edition, but I had
some significant criticisms of his chapter on "Customising LaTeX",
mostly about his choices of macro-names being a source of difficulty
and frustration for editors of journals and collaborative volumes.
Roughly 6 months ago I emailed him about this, and only today has
he responded. I'm expecting to talk with him about it soon by phone.
If you have relevant/candid comments, praises or criticisms, please
send them off-list to me.
Of course the work that we are doing will make his new book pretty-much
out of date before it hits the shelves.
Yet mathematicians are notoriously slow to adapt to the latest changes
in LaTeX, so any bad advice that makes it into this book will probably
still be haunting us for years to come.
>
>
> chris
Cheers to all,
Ross
------------------------------------------------------------------------
Ross Moore ro...@maths.mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 +2 9850 8955
Sydney, Australia 2109 fax: +61 +2 9850 8114
------------------------------------------------------------------------
Chris Rowley
example (too much and too brief probably, apologies). Actually this
mostly applies to ordinary TeX but with the flexibility to influence
how many families and types we have in future TeX's, it is sensible to
look at them now.
TeX (and XeTeX) provides three mechanisms for changing the font slot
accesed by a character (or, equivalently, a control sequence bound by
a \mathchardef). Here are some factoids and hypotheses to start on an
evaluation of which to use.
1. Change the mathcode (or mathchardef).
2. Use type 7 and change the value of \fam.
3. Change the font accessed by a given family.
2. and 3. will, of course, affect a whole collection of characters but
this is often what is required.
Currently, there is `only one type 7' but it would be possible to
extend this idea (and make it independent of the other uses of `math
type').
1. is by far the most flexible but also the least efficient at run
time: in principle, all 2^N mathcodes may need changing (twice),
plus a few million mathchardefs, just to typeset a single bold
symbol!!
2. only works for a single subset of Ord characters. (Extending it
needs further extensions to TeX.)
3. in XeTeX this can be very flexible (since each font can have its own
XeTeX font-mapping); how efficient is it?
Both 2. and 3. depend on careful and standardised use of the families
(will 256 be enough?). So may 1., if only to make it tractable to
produce the needed tables and _get them right_.
A combination of all three is probably the answer.
The abstract outline of an example implementation using 3.:
a: let X be a subset of Unicode characters that will always `use
glyphs from' a common (but not fixed) font
More formally:
Given t (time),
\forall c,c' \in X, the fonts used to render c,c' ,
f_t(c),f_t(c') , are equal;
But f_t may not equal f_t' for another time t'.
b: associate a XeTeX math-font-family FF(X) with this subset;
c: to change the glyph slection for all c \in X, change only f(FF(X))
(Note that the f_t above lift naturally to the map of math-font-families
to fonts...or something is universal in a suitable category of push-outs:-)...)
A suitable high-level interface could perhaps hide which method is
used to implement, eg, \bm.
The syntax supported in MathML is perhaps relevant to the math
alphabets bit. I got this from Mr MathML himself:
MathML does have the analogues of \mathfrac and friends, if you go
<mi mathvariant="fraktur">a</mi> you get a fraktur a without
requiring that you type the unicode character for a MATHEMATICAL
FRAKTUR SMALL A (𝔞). However for more or less purely
political reasons, the mathml spec says that
`mathvariant is defined to be a unicode-to-unicode mapping'.
In these terms, one of our choices is whether these unicode-to-unicode
mappings are implemeted indirectly by changing the mathcodes or
directly (but maye less intutively) by changing XeTeX's
unicode-to-unicode font-mapping (this must, currently at least, be
done by changing the XeTeX font).
Will Robertson
Before I retire to bed: good and pertinent comments. It's important to
start thinking about this early, I think. Two things: when Taco
integrates pdfTeX and Aleph (right?), will OTPs be able to fulfill the
same task as XeTeX's font mappings?
Maybe it would be a good idea to involve him in this discussion...
On Nov 21, 7:11 pm, Chris Rowley <C.A.Row...@open.ac.uk> wrote:
>
> TeX (and XeTeX) provides three mechanisms for changing the font slot
> accesed by a character (or, equivalently, a control sequence bound by
> a \mathchardef). Here are some factoids and hypotheses to start on an
> evaluation of which to use.
You missed one:
4. not at all. (!)
This breaks backwards compatibility, of course. But such methods
shouldn't be technically required given the aims of unicode, so I think
acknowledging this fact is important.
Considering the eventual changes we're looking at with LaTeX maths
(Morten tells me breqn may possibly become actively maintained at some
stage in the future...), and improvements that can be made (see the
recent LaTeX package "cool", which encodes mathematical meaning rather
than just symbols) -- how important is backwards compatibility with
\mathbf, \mathsf, etc.?
Do we want \mathbfitsans{} -like macros or would a more NFSS scheme be
better?
At this stage, I'm more inclined to simply provide single command names
for the individual characters:
\bfitsanspartial
(Boy, that symbol's covering bases :) I guess you never know...)
> Mr MathML
Who's that?
Will
Ross Moore
On 22/11/2006, at 2:33 AM, Will Robertson wrote:
> Considering the eventual changes we're looking at with LaTeX maths
> (Morten tells me breqn may possibly become actively maintained at some
> stage in the future...), and improvements that can be made (see the
> recent LaTeX package "cool", which encodes mathematical meaning rather
> than just symbols) -- how important is backwards compatibility with
> \mathbf, \mathsf, etc.?
>
> Do we want \mathbfitsans{} -like macros or would a more NFSS scheme be
> better?
>
> At this stage, I'm more inclined to simply provide single command
> names
> for the individual characters:
> \bfitsanspartial
>
> (Boy, that symbol's covering bases :) I guess you never know...)
Here's how I see this kind of thing working.
Take an example of blackboard-bold `R' as used in mathematics
to denote the "Real Numbers".
TeX doesn't actually care about what the symbol is used to represent,
though Unicode does (sort of) and most users certainly do.
\BbbR refers to the concept of a double-struck R
This should be a robust macro in LaTeX.
\BbbR ---> \mathbb{R}
denotes that this symbol is just one of many
that are treated in a similar way.
\mathbb{#1} implements how to obtain the desired character.
(alternatively, \mathbb is also robust, and expands
into an internal macro \@mathbb that does the stated job)
In XeTeX, \@mathbb can be implemented as
(i) consideration for the correct size and spacing within math;
(ii) a font-switch e.g., to Code2000 ;
(iii) with an ascii->unicode character-map .
In particular R |---> "211D .
This allows several places to cope with special cases.
e.g.
1. \BbbR might need to be implemented quite differently
to all other \mathbb letters; this is possible.
2. when using Code2000 and Code2001 there are 2 fonts
involved, and XeTeX character-maps cannot change font.
So \@mathbb must test its argument to decide whether
we need Code2000 or Code2001 .
There will be a different character-map for each of these.
3. in other places (e.g. for book-marks) there can be
encoding-specific expansions, to either \mathbb or \BbbR ;
e.g., as part of the expansion to \pdfstringdef
or its "PreHook" token-list.
Now what if the input stream contains the raw character ℝ
(obtainable in XeTeX also by ^^^^211d ).
Here's the possibly contentious part.
I'd say that this character should be active within math,
as follows:
{\catcode"211D \active \global\let ^^^^211d \BbbR }
\mathcode"211D = 8000
This allows:
ℝ in text-mode remains as-is, being placed into the PDF
if the text-font has the correct glyph available;
ℝ in math-mode automatically becomes \BbbR and is handled
consistently with other instances.
Of course, an actual mathematical author should make a macro
definition:
\newcommand{\Reals}{\BbbR}
or \providecommand{\RR}{\BbbR}
or just \let\RR\BbbR ,
and use the locally grown macro in his/her document source,
to enhance its readability to another mathematician/editor.
Because \BbbR is robust, this will not cause any problems
in tables of Contents, Indexes, etc. that may be prepared
separately from the processing of the main document.
A user must *not* do:
\DeclareRobustCommand{\RR}{\BbbR}
for this can lead to undefined macros written into .toc files, etc.
>
>> Mr MathML
>
> Who's that?
Is this Robert Miner ?
Or just Chris' way of referring to the MathML Specs.
Doh! -- surely he means David Carlisle.
>
> Will
Morten Høgholm
> \mathbb{#1} implements how to obtain the desired character.
> (alternatively, \mathbb is also robust, and expands
> into an internal macro \@mathbb that does the stated job)
Just a small comment: I changed the internal name to \mathbb<space> in the
2005/12/01 LaTeX release since the \@-form caused problems in certain
areas plus it fits better with all other robust commands including the
\textXX ones.
--
Morten
Chris Rowley
http://www.appliedsymbols.com/um/
chris
Will Robertson
> unimath seesm to already be a product:
>
> http://www.appliedsymbols.com/um/
Didn't think through that one too far, did I?!
Well, what do you reckon? I don't mind the clash, but I'm open to
suggestions. Perhaps "unimaths" would be more appropriate, then.
Will
Ross Moore
On 23/11/2006, at 9:59 AM, Will Robertson wrote:
>
> On Nov 23, 8:02 am, Chris Rowley <C.A.Row...@open.ac.uk> wrote:
>> unimath seesm to already be a product:
>>
>> http://www.appliedsymbols.com/um/
>
> Didn't think through that one too far, did I?!
Hmm, they have a font of math-symbols which may need to be supported
in (Xe)TeX sometime. So they have a right to the name.
> Well, what do you reckon? I don't mind the clash, but I'm open to
> suggestions. Perhaps "unimaths" would be more appropriate, then.
No, not really.
It's all too close to the same thing.
Besides, shortening unicode to uni doesn't have the right
connotation for me.
What about municode ? ( Oops: http://www.municode.com/ )
or unicmath ? --- no hits there
Nothing better springs to mind.
> Will
Cheers,
Will Robertson
> What about municode ? ( Oops: http://www.municode.com/ )
> or unicmath ? --- no hits there
Not bad!
I like neumath, but that's similarly taken as municode.
umath -- has more google hits, but less collision with anything.
Maybe I'll just bite the bullet: "unicode-math.sty"
Will
Chris Rowley
Will
> Before I retire to bed: good and pertinent comments. It's important to
> start thinking about this early, I think. Two things: when Taco
> integrates pdfTeX and Aleph (right?), will OTPs be able to fulfill the
> same task as XeTeX's font mappings?
>
Not as they currently are: they are never used at in math mode.
> Maybe it would be a good idea to involve him in this discussion...
I think we should clarify our own ideas first: Taco knows little of
maths.
>
> On Nov 21, 7:11 pm, Chris Rowley <C.A.Row...@open.ac.uk> wrote:
> >
> > TeX (and XeTeX) provides three mechanisms for changing the font slot
> > accesed by a character (or, equivalently, a control sequence bound by
> > a \mathchardef). Here are some factoids and hypotheses to start on an
> > evaluation of which to use.
>
> You missed one:
> 4. not at all. (!)
NO! A mathcode is _always_ used. In mathmode there is no current font
and hence no concept of `pass the input chacracter to the font'.
> This breaks backwards compatibility, of course. But such methods
> shouldn't be technically required given the aims of unicode, so I think
> acknowledging this fact is important.
>
I have no idea what you mean here.
I think you misundertand my point. Ross implied that we may wish to
change the font used for any collection of input characters.
I am trying to go right back and decide how all charcaters should be
treated in math mode.
They all can and will change font (if only to get a bold version).
> > Mr MathML
>
> Who's that?
>
David.
Chris Rowley
active' in mathmode
(but I can see Ross'idea and will think about it).
chris
Will Robertson
I guess the biggest limitation at present is XeTeX's 16-bit
mathcodes. In order to be able to input the higher plane characters
(mathematical alphabets) and have them typeset correctly, you'd need
some active character scheme. But this 16-bit limit isn't set in
stone, I believe; we'll have to wait until JK returns from his
holiday to pursue that particular problem.
Will
Will Robertson
By coincidence, I'm able to reply very quickly. I'm having my once-a-
year bout of insomnia. (Hopefully this makes sense, then!)
On 27/11/2006, at 3:36 , Chris Rowley wrote:
> I think you misundertand my point. Ross implied that we may wish to
> change the font used for any collection of input characters.
>
> I am trying to go right back and decide how all charcaters should be
> treated in math mode.
>
> They all can and will change font (if only to get a bold version).
Okay, we were talking crosswise.
Yes, let's assume that at various times, we do want to change a font
used in mathmode. This is tricky right now, since we don't really
have any fonts to test these ideas on; Cambria Math seems to only
exist in a single weight.
There are two situations I can see, which map approximately to
LaTeX's concept behind "\boldmath" and "\bm" (or "\boldsymbol"). In
the first case, \mathversion{bold}, *everything* becomes bold. This
is analogous to switching fonts in text mode.
This is easy to implement on top of the NFSS; just use a mathversion
and switch everything. This implies there will be, say, a "STIX bold"
font that contains the same glyphs as the regular weight, just darker.
And while it is "easy for me", there may very well be more efficient
ways to go about it now, but that's all I can really contribute to
the conversation, I guess -- my lack of understanding of the inner
workings of TeX impede more than help.
***
But the case corresponding to \bm confuses me. Cambria Math, for
example, doesn't contain any bold variations except in the alphabetic
blocks; bold italic latin and greek letters, for example. In fact, I
wonder if bm's ability to make any symbol at all bold (\int?) has
ever been useful. Okay, I know \bm\cdot is quite popular.
Generally speaking, unicode should ideally provide for every
character we desire in a single block of mathematics. The question
is: when do we want to be able to switch fonts halfway through an
equation?
Complications arise with \bm as a general command: for example, if
you're typesetting \itR (U+1D445), how do you know to go to \bfitR (U
+1D479) instead of changing fonts? ... I suppose that's what is under
discussion. This ends up being easiest to implement using font
mappings, since the situation is analogous to how LaTeX does it
originally.
I would feel a lot more comfortable going forward with a
specification of what we're aiming for. For example: we *do* want to
support the exact functionality of \bm and \mathcal and \mathbf (but
what does that mean?) ... because we want unicode-math to support
legacy documents.
I suspect you've had that idea all along, but I've not been aiming so
specifically so far. (More just trying to get stuff working before
getting it working "right".)
Will
Ross Moore
On 27/11/2006, at 5:25 AM, Will Robertson wrote:
>
> Hello,
>
> By coincidence, I'm able to reply very quickly. I'm having my once-a-
> year bout of insomnia. (Hopefully this makes sense, then!)
>
> On 27/11/2006, at 3:36 , Chris Rowley wrote:
>
>> I think you misundertand my point. Ross implied that we may wish to
>> change the font used for any collection of input characters.
>>
>> I am trying to go right back and decide how all charcaters should be
>> treated in math mode.
Fair enough.
>>
>> They all can and will change font (if only to get a bold version).
>
> Okay, we were talking crosswise.
> Yes, let's assume that at various times, we do want to change a font
> used in mathmode. This is tricky right now, since we don't really
> have any fonts to test these ideas on; Cambria Math seems to only
> exist in a single weight.
But we have Code2000 and Code2001 too.
So there is the possibility of testing with different fonts
for the same characters.
>
> There are two situations I can see, which map approximately to
> LaTeX's concept behind "\boldmath" and "\bm" (or "\boldsymbol"). In
> the first case, \mathversion{bold}, *everything* becomes bold. This
> is analogous to switching fonts in text mode.
No, it is not analogous; nor should it be.
You cannot switch \mathversion within math-mode itself.
In LaTeX-2e you must *declare* the math-version before entering
math-mode, just as you must declare the size (via \small, \large,
\Huge, etc.) before entering math-mode.
> This is easy to implement on top of the NFSS; just use a mathversion
> and switch everything. This implies there will be, say, a "STIX bold"
> font that contains the same glyphs as the regular weight, just darker.
>
> And while it is "easy for me", there may very well be more efficient
> ways to go about it now, but that's all I can really contribute to
> the conversation, I guess -- my lack of understanding of the inner
> workings of TeX impede more than help.
>
> ***
>
> But the case corresponding to \bm confuses me. Cambria Math, for
> example, doesn't contain any bold variations except in the alphabetic
> blocks; bold italic latin and greek letters, for example. In fact, I
> wonder if bm's ability to make any symbol at all bold (\int?) has
> ever been useful. Okay, I know \bm\cdot is quite popular.
\bm implemented as "poor-man's bold", by overlaying a symbol with
a slightly shifted 2nd copy, is relegated to the scrap-heap.
It is a visual effect only, which does not encode any changes
to the meaning.
I cannot recall ever having seen \bm\cdot used.
There is a difference (in Unicode) between \cdot at U+022C5
and \bullet (or \smblkcircle) at U+02022
and \vysmblkcircle at U+02219 .
(It's the latter that I suspect people want instead of \bm\cdot .)
>
> Generally speaking, unicode should ideally provide for every
> character we desire in a single block of mathematics. The question
> is: when do we want to be able to switch fonts halfway through an
> equation?
You should not want to switch fonts; just call up different
characters. Using an NFSS-like approach, allowing overrides of
individual symbols, then backward compatibility can be maintained.
Foe example, \bm can behave like a text-accent. It looks at its
argument #1, examines whether \csname \bm\string#1\endcsname
is defined already. If so, then it can use that, as a special case,
else fall back on a general rule to implement the effect.
In the above case, \csname bm\string\cdot\endcsname
would produce \vysmblkcircle , which would then be implemented
in whatever way it would have been at the current math-state
(T or D, or S or SS, in whatever math-version is being used).
>
> Complications arise with \bm as a general command: for example, if
> you're typesetting \itR (U+1D445), how do you know to go to \bfitR (U
> +1D479) instead of changing fonts?
You don't simply go there.
Currently one *should* use \mathbf{R} and that gets you to \bfR ;
but that is an upright symbol.
So I suppose you mean using \bm{R} to get \bfitR .
(Examples on pp.510--511 of Companion 2nd ed.)
Well, we could do this in XeTeX with a font-mapping, *if there
was a declared base-font for maths that had all the glyphs*.
But if we don't assume that option is available, then it would
be necessary to examine each token within the {...}, and
make decisions about what is really required.
This isn't so hard --- hyperref does it all the time --- since,
after all, it is only the normal letters that should be affected;
these are identified by their \catcode . Then a big \ifcase command
could be used, or a token-list of associated pairs:
{A\bfitA\\B\bfitB\\C\bfitC\\....\\Z\bfitZ\\a\bfita\\....\\z\bfitz\\}
with \\ locally-defined adaptively to process this efficiently.
Alternatively, if we do have a separate font with all the symbols bold,
(as the Companion describes for the txfonts), at least for Plane-0 ,
then there should be no real problem.
I can see 2 possibilities, depending upon why bold is being used:
either:
(a) just use this bold font, with a mapping that takes R |---> \itR
(\bm is being used in slides, for effect only
--- why aren't we using \mathversion{bold} ??? )
OR
(b) use the bold font, with a mapping that takes R |---> \bfitR .
This latter way, when a math-expression is copy/pasted from the PDF,
a distinction between \itR and \bfitR can be preserved.
> ... I suppose that's what is under
> discussion. This ends up being easiest to implement using font
> mappings, since the situation is analogous to how LaTeX does it
> originally.
> I would feel a lot more comfortable going forward with a
> specification of what we're aiming for. For example: we *do* want to
> support the exact functionality of \bm and \mathcal and \mathbf (but
> what does that mean?) ... because we want unicode-math to support
> legacy documents.
>
> I suspect you've had that idea all along, but I've not been aiming so
> specifically so far. (More just trying to get stuff working before
> getting it working "right".)
Sure. You need to know the extent of what you can do,
before deciding what is the right thing to be doing.
(Hopefully the right thing is not impossible to achieve.)
As you experiment with the possibilities, please do *not*
announce unimath.sty (or whatever) as a working package,
for people to use outside this list. That will create a
real headache later, as people try to get extra functionality
out of earlier, incomplete versions.
>
> Will
Now I have to turn to marking exam papers,
at least for a few hours each day.
Cheers,
Will Robertson
> \bm implemented as "poor-man's bold", by overlaying a symbol with
> a slightly shifted 2nd copy, is relegated to the scrap-heap.
> It is a visual effect only, which does not encode any changes
> to the meaning.
Good! We only want bold to have real meaning, then.
> I cannot recall ever having seen \bm\cdot used.
> There is a difference (in Unicode) between \cdot at U+022C5
> and \bullet (or \smblkcircle) at U+02022
> and \vysmblkcircle at U+02219 .
> (It's the latter that I suspect people want instead of \bm\cdot .)
I'll have to investigate more; I remember Bruno Voisin requiring to use
it for a specific journal to denote dot product of vectors (as opposed
to regular multiplication, or as an empty argument to a function, e.g.,
$F(\cdot)$ ). I don't really think the distinction is necessary, but I
do like the extra "weight" in the CM fonts that this gives when using
dot product.
I just corrected a friend from using \bullet as dot product in one of
his papers. Ugh, so ugly.
> Foe example, \bm can behave like a text-accent. It looks at its
> argument #1, examines whether \csname \bm\string#1\endcsname
> is defined already. If so, then it can use that, as a special case,
> else fall back on a general rule to implement the effect.
>
> In the above case, \csname bm\string\cdot\endcsname
> would produce \vysmblkcircle , which would then be implemented
> in whatever way it would have been at the current math-state
> (T or D, or S or SS, in whatever math-version is being used).
I think the only "general rule" possible at this stage would be switch
to the font used for the bold maths version. BB's table provides data
for which symbols should have bold versions, but I don't know how the
STIX fonts will actually use this data.
Otherwise, I'm afraid we will have to create a huge mapping for \bm. At
this stage I don't know how to make this stage robust with respect to
the possibilities of some glyphs not being available in some fonts.
> > Complications arise with \bm as a general command: for example, if
> > you're typesetting \itR (U+1D445), how do you know to go to \bfitR (U
> > +1D479) instead of changing fonts?
(Yes, I was using the macro \itR to denote the regular weight italic
mathematical letter R.)
> You don't simply go there.
> Currently one *should* use \mathbf{R} and that gets you to \bfR ;
> but that is an upright symbol.
Simply don't go where? My question was how to resolve \mathbf{R} -->
\bfR (or whatever) without switching fonts (since good fonts will
contain both glyphs). I guess a big table and/or mapping is indeed the
way to go.
> Well, we could do this in XeTeX with a font-mapping, *if there
> was a declared base-font for maths that had all the glyphs*.
>
> But if we don't assume that option is available, then it would
> be necessary to examine each token within the {...}, and
> make decisions about what is really required.
What have I gotten myself into...the way forward certainly isn't clear
to me right now.
***
> Sure. You need to know the extent of what you can do,
> before deciding what is the right thing to be doing.
> (Hopefully the right thing is not impossible to achieve.)
:)
***
> As you experiment with the possibilities, please do *not*
> announce unimath.sty (or whatever) as a working package,
> for people to use outside this list. That will create a
> real headache later, as people try to get extra functionality
> out of earlier, incomplete versions.
Okay, this sounds like a very good idea. When things start shaping up,
however, I'll be more public about the existance of the package in case
people want to see what's going on.
Will
Ross Moore
On 27/11/2006, at 11:32 AM, Will Robertson wrote:
>
> Ross Moore wrote:
>> I cannot recall ever having seen \bm\cdot used.
>> There is a difference (in Unicode) between \cdot at U+022C5
>> and \bullet (or \smblkcircle) at U+02022
>> and \vysmblkcircle at U+02219 .
>> (It's the latter that I suspect people want instead of \bm\cdot .)
I wrote this without checking the symbols, as available in some fonts.
I had meant to compare:
U+000B7 (\cdotp in BB's table) <MIDDLE DOT>
with
U+022C5 (\cdot in BB's table) <DOT OPERATOR> .
The latter is much heavier than the former, which is like
a raised '.' ; yet it is the former that \cdot currently
gives you in (non-Xe)LaTeX .
In practice, I'd expect $A\cdot B\cdot\cdots\cdot Z$ to look
rather like:
A U+022C5 B U+022C5 U+000B7 U+000B7 U+000B7 U+022C5 Z
where you can easily see the difference in size of the dots.
(Yes, I know there is a separate character for \cdots :-).
The point is that currently TeX makes all the dots the same size,
and I think this is actually wrong.
>
> I'll have to investigate more; I remember Bruno Voisin requiring to
> use
> it for a specific journal to denote dot product of vectors (as opposed
> to regular multiplication, or as an empty argument to a function,
> e.g.,
> $F(\cdot)$ ). I don't really think the distinction is necessary, but I
> do like the extra "weight" in the CM fonts that this gives when using
> dot product.
Bruno should be using XeTeX now, and can get at ^^^^22c5 directly.
Indeed: \mathop{^^^22c5} or \mathop{\char"22C5} .
:-)
> I just corrected a friend from using \bullet as dot product in one of
> his papers. Ugh, so ugly.
Yes; that is too heavy.
> Otherwise, I'm afraid we will have to create a huge mapping for \bm.
Maybe. The source may look ugly, but it'll process very quickly.
> At
> this stage I don't know how to make this stage robust with respect to
> the possibilities of some glyphs not being available in some fonts.
>
>>> Complications arise with \bm as a general command: for example, if
>>> you're typesetting \itR (U+1D445), how do you know to go to
>>> \bfitR (U
>>> +1D479) instead of changing fonts?
>
> (Yes, I was using the macro \itR to denote the regular weight italic
Actually, I don't like BB's use of \itR .
It is "math italic R", so the name ought to be \mitR .
This is less likely to be clobbered by accident.
> mathematical letter R.)
>> As you experiment with the possibilities, please do *not*
>> announce unimath.sty (or whatever) as a working package,
>> for people to use outside this list. That will create a
>> real headache later, as people try to get extra functionality
>> out of earlier, incomplete versions.
>
> Okay, this sounds like a very good idea. When things start shaping up,
> however, I'll be more public about the existance of the package in
> case
> people want to see what's going on.
Sure; but only when we are very sure about the main aspects.
>
> Will
Will Robertson
> Actually, I don't like BB's use of \itR .
> It is "math italic R", so the name ought to be \mitR .
> This is less likely to be clobbered by accident.
I would agree to such a prefix for all of the alphabetic symbols. There
are some other things that need processing during the conversion of the
STIX table, such as the declaration of text symbols (\# &c.) that
shouldn't be there (in my package) ...
Will
Chris Rowley
> Maybe I'll just bite the bullet: "unicode-math.sty"
>
Probably best: just take care not to swallow the bullet.
chris