Sounds good to me!! Heye Andrew Can you provide little information about your Extension Via PM.
cheers
I didn’t mean to do that, but you like to make the forum better and better, so all’s well that ends well, I hope…
With the STIX fonts, those letters do all look the same, in the curlier script. *** However, I think part of the problem is that the calligraphic BEFHIKLM live in a totally different area of Unicode than the other calligraphic letters. Your ”ℬ” at U+212C certainly doesn’t immediately follow the ”𝒜” at U+1D49C. The very next symbol after ”𝒜” is ”” (undefined), followed by ”𝒞” and ”𝒟”, because the Unicrats who designed these things in their infinite wisdom ensured that only a portion of the “calligraphic” alphabet was put in a different codepage on an alternate plane of existence, where some fonts may or may not even have glyphs, and the glyph may very well look different, because there is absolutely no assurance in Unicode of any consistency in the way fonts are going to be applied across such vastly different planes of the code space. Why isn’t it possible to put real ASCII letters in a calligraphic font? Seems like it should work but it doesn’t, in my browser anyways:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN"
"http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Probability Space</title></head>
<body>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mfenced>
<mi>Ω</mi>
<mi mathvariant='script'>F</mi>
<mi mathvariant='double-struck'>P</mi>
</mfenced>
</math>
</body>
</html>`
P.S.: Congratulations on figuring out how to make this page ill-formed! It took a bit of work to fix the issue.
Perhaps you need to install the STIX fonts (see here for some slightly out-of-date, but still useful instructions).
I see those calligraphic letters all set in the same font. And, moreover $\mathbb{P}$ and $\mathbb{Q}$ are set upright (as, for that matter, are $\mathbb{A}$ and $\mathbb{b}$).
Alas, what you see is strongly-dependent on what fonts you have installed.
In more detail:
On my system, ℬ (U+212C) is available in STIXGeneral
, Apple Symbols
and Arial Unicode MS
. But 𝒜 (U+1D49C) is only available in STIXGeneral
. In current versions of Firefox, I believe the default value of font.mathfont-family
is
MathJax_Main, STIXNonUnicode, STIXSizeOneSym, STIXSize1, STIXGeneral, Asana Math, Symbol,
DejaVu Sans, Cambria Math
so the version in STIXGeneral
is what I see.
Maybe it’s just general persnicketiness on my part, but why do $\mathrm{\mathcal{B}\mathcal{E}\mathcal{F}\mathscr{H}\mathcal{I}\mathcal{L}\mathcal{M}\mathcal{R}}$ appear (in Firefox and rekonq) in a different type than the letters $\mathrm{\mathcal{A}\mathcal{C}\mathcal{D}\mathcal{G}\mathcal{J}\mathcal{K}\mathcal{N}\mathcal{O}\mathcal{P}\mathcal{Q}\mathcal{S}\mathcal{T}\mathcal{U}\mathcal{V}\mathcal{W}\mathcal{X}\mathcal{Y}\mathcal{Z}}$? And how can I get a letter like $\mathbb{P}$ or $\mathbb{Q}$ to stand upright like $\mathrm{\mathbb{P}\mathbb{Q}}$ but by itself without getting italicized?
(Sorry for the new username. I lost my password and for some reason Yahoo can’t get mail from the forums.)
Good enough then and thank you. I thought $X_a b$
was producing an unacceptable space, but that was just a Firefox peculiarity.
That’s a “feature”, not a bug.
As described here, $ab$
is a single token in itex (tranlated to <mi>ab</mi>
); $a b$
are two tokens (translated to <mi>a</mi><mi>b</mi>
). MathML is semantically-richer than (La)TeX, and this convention gives you the ability to enter multi-character tokens, which will be interpreted as such, when translated to MathML.
Identifiers lumped together in MathML output
Example: $X_ab$
produces output ${X}_{\mathrm{ab}}$ <msub><mi>X</mi> <mi>ab</mi></msub>
Output should be more or less ${X}_{a}b$ <math><msub><mi>X</mi> <mi>a</mi></msub><mi>b</mi></math>
Two things wrong with this: first the “b” would never be subscripted in LaTex, and second, two variables should not be lumped in the same <mi></mi>
element because this causes MathML to set them in upright rather than italic type. So each variable really needs to be in its own <mi></mi>
That’s cool. I’m sure other people would be interested in your PHP extension. So you should think of packaging it for distribution (Pear?).
I thought it might be worth noting that the nForum (and the other mathematical forums that I run) now use itex directly in PHP. (I probably won’t get the words right on this) That is, I’ve compiled itex2MML into a PHP extension (using swig) and am calling that now instead of farming the conversion off to the nLab. I’ve also installed MathJaX to support (as best I can) non-compliant browsers.
I notice that Frederic has now closed this and says that the correct way to handle them is with movablelimits="false"
. So that makes this now an itex bug again!
According to Frédéric, it’s a feature, not a bug. I could change \widehat{}
(and its cousins) to wrap their output in an <mstyle displaystyle='true'>
, but that might have unintended side-effects.
Seems that I can so I have.
‘Cept it’s not a Firefox bug; it’s a Gecko Core (MathML Component) bug. As filed, no one relevant will see it. If you, as the Reporter of the bug, can reclassify it, maybe it will have a fighting chance of getting some attention.
(My word, but that’s a complicated form. “What did you do?” I looked at a MathML web page. “What happened?” It didn’t look right. “What should have happened?” It should have looked right.)
Correct.
The accents work correctly when accenting an <mi>
(see this old bug), but not when accenting an <mo>
, unless the style is displaystyle
.
Thus:
MathML | Display |
---|---|
<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mover><mo>⊗</mo><mo>^</mo></mover></math> | $\hat{\otimes}$ |
<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mstyle displaystyle='true'><mover><mo>⊗</mo><mo>^</mo></mover></mstyle></math> | $\hat{\otimes}$ |
<math display='block' xmlns='http://www.w3.org/1998/Math/MathML'><mover><mo>⊗</mo><mo>^</mo></mover></math> | $$\hat{\otimes}$$ |
<math display='inline' xmlns='http://www.w3.org/1998/Math/MathML'><mstyle textstyle='true'><mover><mo>⊗</mo><mo>^</mo></mover></mstyle></math> | $\hat{\otimes}$ |
You should file a bug report.
This looks like a bug in how Firefox renders MathML, but I thought I’d check with you first. How do $\hat{\otimes}$ and $\hat{\otimes}$ look to you? To me, the first has the hat offset to the right. I presume that it shouldn’t be so.
The optional argument syntax for extensible arrows doesn’t swallow spaces correctly. If I type \xrightarrow [a]{b}
then in LaTeX, this is equivalent to \xrightarrow[a]{b}
because spaces are automatically swallowed after commands. However, in iTeX then they are not equivalent:
Once again: thank you very much!
It’s a matter of the precedence rules that you expect not being respected by itex2MML
\lim_{n\to 0}
is set with an <munder>
. But, when you type
\displaystyle \lim_{n\to 0}
the precedence of the ”_
” is not treated as being higher. The above is treated as equivalent to
{ \displaystyle \lim }_{n\to 0}
which is set with an <msub>
. Putting in the grouping explicitly:
\displaystyle { \lim_{n\to 0} }
gives you what you were expecting.
I think this is confusing. Probably, you were expecting \displaystyle
to behave more like \color{red}
does (compare the definitions of COLOR
and of DISPLAY
, respectively, in itex2MML.y
).
Let’s see: $\underset{n\to 0}{\mathrm{lim}}\frac{1}{n}=0$
Yup. itex2MML 1.4.8 works as you’d expect.
Here’s an anti-feature request. itex2MML should never implement \newcommand
(or any of its variants). Here’s my reasoning:
If done properly, it leaves one open to the \newcommand{\a}{\a}\a
bug. If that isn’t allowed, then it won’t be close to LaTeX’s \newcommand
and people will get trapped by the difference.
It would make it harder to truly collaborate. Every page with more than one editor is going to require reading the preamble just to find out what the local conventions are and that’s going to make it harder to edit something that someone else started.
(Repost from the other discussion as this looks bug-like to me.)
Okay, let’s try this here. Compare and contrast:
How it ought to look:
With a \displaystyle
at the start. In LaTeX, this is to ensure that the subscript to \lim
is underset.
Now with a bit of grouping to help.
Somehow, the <mstyle displaystyle="true">
is getting inside the \lim
processing, turning the <munder>
in to a <msub>
.
What should itex2MML
do, that it doesn’t, currently?
Discuss bugs in itex2MML.