Issue 126357 - Letters not in italics if preceded by number
Summary: Letters not in italics if preceded by number
Status: CLOSED DUPLICATE of issue 45689
Alias: None
Product: Math
Classification: Application
Component: ui (show other issues)
Version: 4.1.1
Hardware: All All
: P5 (lowest) Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-08 14:31 UTC by lapsap7+ooo
Modified: 2015-06-08 15:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
1st line: OK; 2nd line: not OK; 3rd line: workaround (27.52 KB, image/png)
2015-06-08 14:31 UTC, lapsap7+ooo 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description lapsap7+ooo 2015-06-08 14:31:54 UTC 
Created attachment 84778 [details]
1st line: OK; 2nd line: not OK; 3rd line: workaround

Let's consider the following math expression:
ab^2

When it's typed inside OOMath like this, the rendered result is OK (cf attached image).

However, when the expression is like this:
4ab^2
ie, there's *a number preceding the variables*, the rendered result is NOT OK.
Indeed, the variables are not in italics (cf attached image)

For the moment, a workaround would be artificially adding a space after the number as shown in the third line in attached image:
4 ab^2

But in math typesetting, this is not needed nor recommended.

It seems like OOMath is confused when there's a number and is unable to determine if a letter is variable or not!
Comment 1 Regina Henschel 2015-06-08 15:45:30 UTC 
This is an old problem and we have already issue 45689 for it. The underlying problem is, that the language "starmath" has no equivalent to the MathML operators "⁢" and "⁣".

The current behavior has been introduced with the fix for bug 11752. The relevant file is starmath/source/parse.cxx around line #460 in method SmParser::NextToken().

*** This issue has been marked as a duplicate of issue 45689 ***