Closed
Bug 320294
(upright-mi)
Opened 19 years ago
Closed 12 years ago
too much space between upright <mi> elements
Categories
(Core :: MathML, defect)
Core
MathML
Tracking
()
RESOLVED
FIXED
mozilla13
People
(Reporter: dmharvey, Assigned: francoiswang)
References
Details
(Whiteboard: [good second bug])
Attachments
(1 file, 3 obsolete files)
1.47 KB,
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/416.12 (KHTML, like Gecko) Safari/416.13 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 There is too much space between the "a" and "b" in the following kind of markup: <mi fontstyle="normal">a</mi> <mi fontstyle="normal">b</mi> The space does not occur if one leaves out the font attributes altogether, i.e. <mi>a</mi> <mi>b</mi> or if you use MathML version 2 font attributes, i.e. <mi mathvariant="normal">a</mi> <mi mathvariant="normal">b</mi> This bug appears to be a partial relapse of comment 78 from bug 120198. That bug apparently got fixed for firefox 1.5, but what I'm describing here looks quite similar. Reproducible: Always Steps to Reproduce: 1. View a document containing the above MathML 2. 3. Actual Results: Too much space between "a" and "b" Expected Results: Essentially no space between "a" and "b". The behaviour should be identical to the situation where the "mathvariant" attribute is used instead.
Updated•19 years ago
|
Assignee: nobody → rbs
Component: General → MathML
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Reporter | ||
Comment 1•19 years ago
|
||
And see also bug 306543 (which I couldn't quite find before....)
Seems to me that mathvariant should cause an inter-space. Don't we want a spacing at all between such tokens?!? Otherwise how does one distinguish with <mi>ab</mi>?
Reporter | ||
Comment 3•19 years ago
|
||
Reporter | ||
Comment 4•19 years ago
|
||
I disagree with rbs (comment 2). The problem is that if Firefox always puts a space between <mi> tokens, then there is *no* mechanism for an authoring tool to override this and force zero space. Sure, you can put them in the same <mi> block, but then what if you want to place two identifiers next to each other, which have different fonts? Or what if the second character is the base of a subscript? If the default space was zero, then the authoring tool always could use <mspace> to override this if it so desires. Another way to put this is: TeX doesn't put any space between adjacent "identifiers" (in so far as that makes sense), and it looks *good* that way. See attachment (should have said "comment #4") for an example of what I mean. The first image is what I want it to look like. The second image is the best I could do with the current Firefox behaviour. (Image was produced with TeX.)
What about <mi>AA</mi> <mi>x</mi>? (Think <mi>sin</mi> <mi>x</mi>) See the inter-spacing table here: http://lxr.mozilla.org/mozilla/source/layout/mathml/base/src/nsMathMLContainerFrame.cpp#1186 It puts an inter-space between Upright and Italic and between Upright and Upright. Should I revisit the table and disable all the inter-space, except when ⁡ is there? That is, treat "<mi>sin</mi> <mi>x</mi>" differently from "<mi>sin</mi> <mo>&af</mo> <mi>x</mi>". In other words, no space in the first, but inter-space in the second?
Reporter | ||
Comment 6•19 years ago
|
||
That sounds like a good solution to me. I guess that's what ⁡ is there for!
Be sure to think more about the consequences & be clear about the edge cases... "<mi>T</mi> <mo>&af</mo> <mi>x</mi>" "<mi fontstyle="normal">T</mi> <mo>&af</mo> <mi>x</mi>"
Reporter | ||
Comment 8•19 years ago
|
||
I would have thought the spacing in the two examples in comment 7 should be the same. The first is kind of like "T is a function which happens to be written in italics". (Disclaimer: I am somewhat disinterested in the ⁡ case, since the code I am writing will never emit ⁡.)
> the code I am writing will never emit ⁡
How then do you intend to markup "\sin x"?
Reporter | ||
Comment 10•19 years ago
|
||
Using <mspace>. I am trying to write code which emulates TeX as closely as possible, and therefore needs fine control over spacing. Other converters, trying to achieve different objectives, may prefer to use ⁡.
Comment 11•19 years ago
|
||
I am not a big fan of such an approach. This is the web, not pdftex... I like ⁡ better, or <mo lspace=".3em" rspace=".3em">sin</mo>, which is also recommended/accessible, and does what \mathop does in TeX, without being alienated.
Reporter | ||
Comment 12•19 years ago
|
||
I'm not the biggest fan either, but I don't want to get into a long discussion here, because that would force me to justify several major design decisions and several months of hard work :-) Let's just say that my code works out all the spacing according to TeX's rules, and consequently knows how much space there should be between "sin" and "x". The easiest thing to do, and what the code currently does, is to use <mspace>. Maybe I'll change it to use ⁡ more intelligently at some point. But this seems to be a bit off-topic. The question is: will you make the changes you described above?
Comment 13•19 years ago
|
||
Possibly. You can already collapse the inter-space with <mspace/> <mi fontstyle="normal">A</mi> <mspace width="0"/> <mi fontstyle="normal">x</mi> <mo>=</mo> <mi>λ</mi><mspace width="0"/> <mi fontstyle="normal">x</mi> See? I was warry of polluting the markup. I have less enticement if/when your are intentionally mspace-happy.
Reporter | ||
Comment 14•19 years ago
|
||
Thanks for pointing this out. I hadn't realised that <mspace width="0"/> would solve my problem. So perhaps a truce :-) If you don't make any changes, then I'll make my code emit <mspace width="0"/> between any pairs of adjacent <mi> tokens (also <mn> tokens? <mtext>?), and we'll both be partially happy. Related question: I notice that <mspace/> has the same effect as <mspace width="0"/> in this context. Can this behaviour be relied on? I'm not sure exactly what you mean by "I have less enticement if/when your are intentionally mspace-happy."
Comment 15•19 years ago
|
||
I mean that if you are sooo happy to use mspace (which is already possible), then maybe I should concentrate more on the crashers :-) I have a number of them on my back right now and they have been earmarked by the drivers for 1.8.1 because of their potentially security-sensitive nature.
Updated•15 years ago
|
QA Contact: ian → mathml
Updated•14 years ago
|
Assignee: rbs → nobody
Comment 16•14 years ago
|
||
Again found this bug when executed Testcase id 54
Comment 17•14 years ago
|
||
Executed TC 45(TC document 4.5) & was able to reproduce
Comment 18•14 years ago
|
||
Which testcase are you talking about?
Comment 19•14 years ago
|
||
Executed TC 45 & was able to reproduce
Comment 20•13 years ago
|
||
There have recently been some reports from MathJax users of this issue. In MathJax, \mathrm{var} generates <mi mathvariant="normal">v</mi> <mi mathvariant="normal">a</mi> <mi mathvariant="normal">r</mi> and so is rendered "v a r" in Firefox, whereas the users would like to see only one variable "var". It does not seem possible to ask MathJax to force the generation of one <mi> since in other cases such that "2xy" we want to split into several tokens. The MathML spec says: "A typical graphical renderer would render an mi element as its content (See Section 3.2.1 MathML characters in token elements), with no extra spacing around it (except spacing associated with neighboring elements)."
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Whiteboard: [good second bug]
Version: 1.8 Branch → Trunk
Updated•13 years ago
|
Blocks: mathml-in-mathjax
Comment 21•12 years ago
|
||
I think someone working on this will have to look to these parts of the code: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLTokenFrame.cpp#78 http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLContainerFrame.cpp#1094
Comment 22•12 years ago
|
||
I had a look at this bug with François this week-end. Apparently, it's just a matter of modifying an entry in kInterFrameSpacingTable. I don't know if a reftest is necessary but I guess comparing <mi mathvariant="normal">var</mi> and <mi mathvariant="normal">v</mi><mi mathvariant="normal">a</mi><mi mathvariant="normal">r</mi> should work fine.
Assignee: nobody → francoiswang
Assignee | ||
Comment 23•12 years ago
|
||
It looks like eMathMLFrameType_UprightIdentifier is only used with the mi tag. http://mxr.mozilla.org/mozilla-central/ident?i=eMathMLFrameType_UprightIdentifier So it seems ok to change the value 0x01 in the spacing table as it is only used in the GetInterFrameSpacing: http://mxr.mozilla.org/mozilla-central/ident?i=GET_INTERSPACE So I changed the value (Upright, Upright) to 0x00, and now there is not too much space between the <mi> tags and mathvariant="normal". Without the mathvariant="normal" the frame type is eMathMLFrameType_ItalicIdentifier and in the spacing table the value of (Italic, Italic) is already set to 0x00. Regarding reftests: <mi mathvariant="normal">var</mi> and <mi mathvariant="normal">v</mi><mi mathvariant="normal">a</mi><mi mathvariant="normal">r</mi> These two tests look different, in the second test after some letters (for instance "a" or "i"), there is a tiny space (and we don't see it unless we compare the two tests). But actually, the same happens when frame type is Italic: <mi>var</mi> and <mi>v</mi><mi>a</mi><mi>r</mi> The second test is not rendered with the same width. So we cannot use <mi>var</mi> as a reftest, but it is still possible to have the same render if we choose a string that only contains letters without the tiny space behind (for instance <mi>v</mi><mi>v</mi><mi>v</mi> should work) I will attach the patch today (value 0x00 in the spacing table).
Assignee | ||
Comment 24•12 years ago
|
||
This attachment shows the current spacing with mathvariant="normal". After some letters (f or i), the spacing is more important.
Assignee | ||
Comment 25•12 years ago
|
||
With the value 0x00 in the table, spacing is better with mathvariant="normal". But we can see a space after the letters a, f, i, k, l , m, r, t. And a space before the letter j.
Assignee | ||
Comment 26•12 years ago
|
||
Attachment #603754 -
Flags: review?(karlt)
Updated•12 years ago
|
Attachment #603754 -
Flags: review?(karlt) → review+
Comment 27•12 years ago
|
||
(In reply to François Wang from comment #23) > <mi mathvariant="normal">var</mi> > > and > > <mi mathvariant="normal">v</mi><mi mathvariant="normal">a</mi><mi > mathvariant="normal">r</mi> > > These two tests look different, in the second test after some letters (for > instance "a" or "i"), there is a tiny space (and we don't see it unless we > compare the two tests). The difference may be due to kerning only being applied when the character are in the same token. But it is OK that these look different as they mean quite different things.
Comment 28•12 years ago
|
||
(In reply to François Wang from comment #23) > So we cannot use <mi>var</mi> as a reftest, but it is still possible to have > the same render if we choose a string that only contains letters without the > tiny space behind (for instance <mi>v</mi><mi>v</mi><mi>v</mi> should work) (In reply to Karl Tomlinson (:karlt) from comment #27) > The difference may be due to kerning only being applied when the character > are in the same token. So maybe it's not a good idea to choose letters without spaces because we don't know exactly on which parameters the kerning depends on and we may get a different results with another font for example. What about comparing <mi mathvariant="normal">v</mi> <mi mathvariant="normal">a</mi> <mi mathvariant="normal">r</mi> with <mtext>v</mtext> <mtext>a</mtext> <mtext>r</mtext> ?
Comment 29•12 years ago
|
||
Only mi frames are eMathMLFrameType_UprightIdentifier, so mtext may be different.
Comment 30•12 years ago
|
||
(In reply to Karl Tomlinson (:karlt) from comment #29) > Only mi frames are eMathMLFrameType_UprightIdentifier, so mtext may be > different. OK, mtext frames are eMathMLFrameType_Ordinary. But in kInterFrameSpacingTable, the spacing between Ord and Ord is also 0x00 so that may give the same result with the patch applied. But do we really need a reftest for this bug?
Comment 31•12 years ago
|
||
I pushed the patch to try server https://tbpl.mozilla.org/?tree=Try&rev=ecef98f7d132 together with the two possibilities mentioned above for reftests: https://hg.mozilla.org/try/rev/752136162710
Comment 32•12 years ago
|
||
I don't think we need to have a reftest. This is an adjustment in aesthetic appearance, and I don't think we have any other mark-ups that should necessarily render exactly the same.
Comment 33•12 years ago
|
||
(In reply to Karl Tomlinson (:karlt) from comment #32) > I don't think we need to have a reftest. This is an adjustment in aesthetic > appearance, and I don't think we have any other mark-ups that should > necessarily render exactly the same. OK, anyway the suggestion in comment 28 works but not the one in comment 23 (there are failures on Windows and Android). Otherwise, all looks good.
Updated•12 years ago
|
Alias: upright-mi
Keywords: helpwanted → checkin-needed
Summary: too much space between <mi> elements (MathML) when "fontstyle" is used → too much space between upright <mi> elements
Updated•12 years ago
|
Attachment #205949 -
Attachment is obsolete: true
Updated•12 years ago
|
Attachment #603750 -
Attachment is obsolete: true
Updated•12 years ago
|
Attachment #603753 -
Attachment is obsolete: true
Comment 34•12 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/4574bdfa0ada
Keywords: checkin-needed
Target Milestone: --- → mozilla13
Comment 35•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4574bdfa0ada
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
See Also: → https://github.com/gvanas/blahtexml/issues/4
You need to log in
before you can comment on or make changes to this bug.
Description
•