Created attachment 68421 [details] I've added arrows and text to the screenshot. They explain it. Problem description: when you give a variable a coefficient, it is no longer recognized as a variable, therefore is not italicized. While it is not a huge problem, it does look bad. Steps to reproduce: 1. In a formula, write a variable with a coefficient. For example, you could type something like '2x' Current behavior: Variables with coefficients are not italicized like those without coefficients are. Expected behavior: Both should be italicized. Platform: Windows 7 64 bit. Browser: N/A
(In reply to comment #0) > Created attachment 68421 [details] > I've added arrows and text to the screenshot. They explain it. > > Problem description: when you give a variable a coefficient, it is no longer > recognized as a variable, therefore is not italicized. While it is not a > huge problem, it does look bad. > > Steps to reproduce: > 1. In a formula, write a variable with a coefficient. > For example, you could type something like '2x' > > Current behavior: > Variables with coefficients are not italicized like those without > coefficients are. > > Expected behavior: > Both should be italicized. > > Platform: Windows 7 64 bit. > > Browser: N/A Hi. I don't know if this issue is 'normal' or not; but there is a simple workaround to avoid it: as you probably have noticed, L.O. Math ignores blank spaces introduced into the formula code. So, if you type: y = 2 x + 3 you will get an italicized x with coefficient 2. Obviously, this makes you lose some little time when typing, but this is better than nothing. Kind regards. Roberto.
A solution is write 2 x + 3 but does not look correctly. The space between "2" and "x" is large, then confuses. There are three ways. Compare: 2x + 3 2 x + 3 nospace{2 x} + 3 this is the best In LaTeX and MathType just type 2x + 3 that looks like nospace{2 x} + 3 in LibreOffice. But in LibreOffice we have to write "nospace{...}" a lot of times This situation exists since OpenOffice and must be corrected
(In reply to comment #2) > A solution is write 2 x + 3 but does not look correctly. The space between > "2" and "x" is large, then confuses. > There are three ways. Compare: > 2x + 3 > 2 x + 3 > nospace{2 x} + 3 this is the best > In LaTeX and MathType just type 2x + 3 that looks like nospace{2 x} + 3 in > LibreOffice. > But in LibreOffice we have to write "nospace{...}" a lot of times > This situation exists since OpenOffice and must be corrected Victor, you're right. But, unfortunately, I don't believe this issue will be solved very soon. Despite the great work done by the LibreOffice development community, Math doesn't seem to be as important as Writer or Calc (or, at least, the communuty doesn't seem to have enough 'human resources' to pay it more attention). Every new release of LibreOffice brings many improvements to these components, but only a few of them are for Math.
Confirmed with: LO 4.0.2.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit
FYI, this was reported to the MathJax user mailing list: https://groups.google.com/forum/#!msg/mathjax-users/_naUsEP0Rxs/OH33AWIc5akJ The code mentions an Open Office bug: https://issues.apache.org/ooo/show_bug.cgi?id=11752 It seems that this behavior was added to allow things like "x_2n" to have "2n" be interpreted as index. I'm not quite sure this fix was correct e.g. MathJax's LaTeX or ASCIIMath input mode interprets it as "x_2 n". Also it's not consistent with "x_2*n" which is interpreted as "x_2 * n". In any cases, the bug here is that "2n" is badly interpreted as a single number instead of 2 times n.
For the current bug, I think the solution is to modify SmParser::NextToken() so that numbers and identifiers are treated as separate tokens i.e. "2n" will be interpreted as "2 n". (BTW, we need to interpret "2 n" as a product, but this can be done in bug 66081). Then if we want to preserve the "x_2n" syntax asked in https://issues.apache.org/ooo/show_bug.cgi?id=11752, the solution will be to modify SmParser::Term() so that a list of numbers and identifiers, not separated by spaces will be grouped into a single SmExpressionNode and returned. Since SmParser::NextToken() skip white spaces, the absence of white space separators should be verified in the SmParser::Term() itself when numbers and identifiers are grouped.
I'm taking this bug. Note that this is really a parsing issue (with consequence on the rendering) rather than a formatting issue.
I've submitted a patch for review: https://gerrit.libreoffice.org/4494 Some remarks: - I've taken care to not regress bugs https://issues.apache.org/ooo/show_bug.cgi?id=45779 and https://www.libreoffice.org/bugzilla/show_bug.cgi?id=55853 - bNumStart was not used (or at least was always false and had no effect). That seems to be dead code not removed. - I'm not sure KParseTokens::IGNORE_LEADING_WS is really necessary since the code skips the white spaces, but I've left this flag anyway.
(In reply to comment #8) > https://www.libreoffice.org/bugzilla/show_bug.cgi?id=55853 Sorry, I meant https://issues.apache.org/ooo/show_bug.cgi?id=11752
Frederic Wang committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=16a0d06f900027401716ddaba25e5c8998562b2d fdo#55853 - improve parsing of concatenated numbers and identifiers. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I think this bug can be closed? Some test cases: 2x should be "2 x" 3x^2 should be "3 x^2" x_2n should be "x_{2 n}" as asked in https://issues.apache.org/ooo/show_bug.cgi?id=11752. The example given there is "font sans bold size *1.5 A =left[matrix{A_11#A_12#dotsaxis#A_1n##A_21#{} #{}#A_2n##dotsvert#{}#{}#dotsvert##A_n1#A_n2#dotsaxis#A_nn}right]" (although "A_nn" is not quite correct, strictly speaking it should be "A_{n n}" but that should not affect the rendering). size *1.9{Aa} should work with e.g. FR locale (https://issues.apache.org/ooo/show_bug.cgi?id=45779)
(In reply to comment #11) > I think this bug can be closed? Sure, you can close the bugs you create/fix for sure :). Especially when you are the expert on this domain ;-). Other developers usually close their fixed bugs too, unless they would like to have a second review. If after a period of time it looks like it isn't fixed, you can REOPEN (or NEW) this bug. Thanks for your work!!
(In reply to comment #12) > Sure, you can close the bugs you create/fix for sure :). Especially when you > are the expert on this domain ;-). Other developers usually close their > fixed bugs too, unless they would like to have a second review. If after a > period of time it looks like it isn't fixed, you can REOPEN (or NEW) this > bug. > > Thanks for your work!! Thanks for the information. I was not sure about the LibreOffice process so preferred to ask. I'll do that myself for future bugs.
Frederic Wang committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=48d696e2049e771ebc797b7a7694e02de89b6020 Tests for fdo#55853, i#11752, fdo#66081 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.