Bug 55853 - Variable with coefficients not italicized
Summary: Variable with coefficients not italicized
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
3.6.1.2 release
Hardware: Other All
: medium normal
Assignee: Frédéric Wang
URL:
Whiteboard: BSA target:4.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-10 20:10 UTC by e325001
Modified: 2021-10-02 16:59 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
I've added arrows and text to the screenshot. They explain it. (107.31 KB, image/png)
2012-10-10 20:10 UTC, e325001
Details

Note You need to log in before you can comment on or make changes to this bug.
Description e325001 2012-10-10 20:10:44 UTC
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
Comment 1 Roberto 2012-10-11 01:07:38 UTC
(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.
Comment 2 Victor 2013-01-27 22:02:30 UTC
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
Comment 3 Roberto 2013-02-14 02:46:50 UTC
(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.
Comment 4 bfoman (inactive) 2013-05-06 08:58:48 UTC
Confirmed with:
LO 4.0.2.2
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit
Comment 5 Frédéric Wang 2013-06-21 18:41:28 UTC
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.
Comment 6 Frédéric Wang 2013-06-23 14:05:06 UTC
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.
Comment 7 Frédéric Wang 2013-06-24 18:16:47 UTC
I'm taking this bug. Note that this is really a parsing issue (with consequence on the rendering) rather than a formatting issue.
Comment 8 Frédéric Wang 2013-06-24 21:24:53 UTC
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.
Comment 10 Commit Notification 2013-06-28 09:58:26 UTC
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.
Comment 11 Frédéric Wang 2013-06-28 10:23:11 UTC
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)
Comment 12 Jorendc 2013-06-28 10:54:45 UTC
(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!!
Comment 13 Frédéric Wang 2013-06-28 11:09:01 UTC
(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.
Comment 14 Commit Notification 2013-07-09 08:12:56 UTC
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.