#5 <munder> doesn't stretch underscript as expected

[Anonymous]

Apparently JEuclid (2.9.6 and 2.9.5 at least) doesn't stretch the underscript of <munder> operator.

Here's a simple example:

<?xml version="1.0"?>
<!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN"
"http://www.w3.org/TR/MathML2/dtd/mathml2.dtd">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<munder accentunder="true">
<mn>456</mn>
<mo>&UnderBar;</mo>
</munder>
</math>

Attached is Amaya rendering (which does the stretching) and JEuclid rendering (mathviewer was used) which does not.

If this is fundamentally difficult to fix, I would welcome any workaround comments - how to achieve desired result.

Thank you!

[Nobody/Anonymous]

Amaya rendering

[Nobody/Anonymous]

Logged In: NO

Apparently I can only upload one file.
I uploaded Amaya's rendering; jeuclid developers can generate jeuclid rendering and see the difference...

[Ernest Mishkin]

Logged In: YES
user_id=1781904
Originator: NO

After a bit of investigation:

1) Looks like there's an issue with Mo.isHorizontalDelimeter() which returns false for &UnderBar;

2) Temporarily changing the above to return true and debugging through the rendering of the original munder example yielded some really odd results:
When Mo.calculateSpecs is called to obtain width/height (not yet to paint) this line
final Rectangle2D textBounds = this.produceUnstrechtedLayout(g).getBounds();
produces rectabgle with getX() == -5 and getWidth() == 5 (rounded, but basically getX() < 0 && -getX() == getWidth())

So this line
final float realwidth = (float) (textBounds.getWidth() + textBounds.getX());
produces 0 and this line
this.calcScaleX = targetwidth / realwidth;
results in division by zero.

I guess I really need Max's or someone else's who is intimate with the rendering code help to tackle this problem.

Please!!!

[Ernest Mishkin]

Logged In: YES
user_id=1781904
Originator: NO

Ok, more research and I'm happy to report that the issue seems to have a pretty narrow scope:

Using <mo strewtchy="true">_</mo> (regular underscore char marked as stretchy) produces desired effect.

Apparently there's something peculiar about how TextLayout calculates bounds for &UnderBar; character. I tried several different fonts (on windows; Tahoma, in particular, does have the character for sure) and every time I get the problem as described in the previous comment.

I'm not stuck any more though as the above mentioned workaround seems to suit me just fine.

--Ernest

[Max Berger]

Logged In: YES
user_id=99210
Originator: NO

1) I have added UnderBar (and all other Under* and Over*) to the list of horizontal delimiters
2) I have written a workaround to ensure that there is no division by zero.

(both in SVN)

The problem with the UnderBar entity is that it is mapped to unicode 332, which is a combining character. Unfortunately these combining characters have very strange metrics, resulting in problems.

What would need to be done is to map UnderBar to the underscore (_) instead, but keep its strechty attribute. I am still thinking about that.

Max

[Max Berger]

Logged In: YES
user_id=99210
Originator: NO

1) I have added UnderBar (and all other Under* and Over*) to the list of horizontal delimiters
2) I have written a workaround to ensure that there is no division by zero.

(both in SVN)

The problem with the UnderBar entity is that it is mapped to unicode 332, which is a combining character. Unfortunately these combining characters have very strange metrics, resulting in problems.

What would need to be done is to map UnderBar to the underscore (_) instead, but keep its strechty attribute. I am still thinking about that.

Max

[Max Berger]

Logged In: YES
user_id=99210
Originator: NO

I have mapped the underbar -> overbar. The render the same anyways, and since the font metrics use only the actual text content, this works very nicely.