FIX: re-order symbol and acent in mathtext

[tacaswell]

Try to find symbols before finding accents

Closes #4462

attn @mdboom What can of worms have I opened here?

[mdboom]

I suspect this change is fine as long as there are no symbols that are strict prefixes of accents. (Don't know if that's the case). Maybe add some tests? (Clearly it doesn't break existing ones, which is a good thing.)

[tacaswell]

@mdboom rebased + tests added

[tacaswell]

Ping me if I should merge these tests into one, the idea was to split them up to make bisection easier

[tacaswell]

ping @mdboom

[zblz]

@tacaswell: In my system this switch messes up the position of the accents. It might be system dependent, but I think my system is common enough that this shouldn't happen (everything from Debian Testing repos except matplotlib master, Python 3.4). Before the fix, accents rendered fine, symbols didn't:

After it, accents are shifted to the left:

I don't know much about parsers, so I don't really understand how this can happen from a cursory glance at mathtext.py. What other info do you need?

[tacaswell]

Well, that is exciting.

On Fri, Aug 7, 2015, 12:19 PM Victor Zabalza notifications@github.com
wrote:

@tacaswell https://github.com/tacaswell: In my system this switch
messes up the position of the accents. It might be system dependent, but I
think my system is common enough that this shouldn't happen (everything
from Debian Testing repos except matplotlib master, Python 3.4). Before the
fix, accents rendered fine, symbols didn't:
[image: accent_test_mpl_cm_old]
https://cloud.githubusercontent.com/assets/576258/9140290/e531d806-3d27-11e5-8022-8d2222c9d6d0.png

After it, accents are shifted to the left:
[image: accent_test_mpl_cm_master]
https://cloud.githubusercontent.com/assets/576258/9140292/ee9dbb3a-3d27-11e5-8fa9-12e87b192b57.png

I don't know much about parsers, so I don't really understand how this can
happen from a cursory glance at mathtext.py. What other info do you need?

—
Reply to this email directly or view it on GitHub
#4588 (comment)
.

[WeatherGod]

What is the mathtex string you are using?

On Fri, Aug 7, 2015 at 12:24 PM, Thomas A Caswell notifications@github.com
wrote:

Well, that is exciting.

On Fri, Aug 7, 2015, 12:19 PM Victor Zabalza notifications@github.com
wrote:

@tacaswell https://github.com/tacaswell: In my system this switch
messes up the position of the accents. It might be system dependent, but
I
think my system is common enough that this shouldn't happen (everything
from Debian Testing repos except matplotlib master, Python 3.4). Before
the
fix, accents rendered fine, symbols didn't:
[image: accent_test_mpl_cm_old]
<
https://cloud.githubusercontent.com/assets/576258/9140290/e531d806-3d27-11e5-8022-8d2222c9d6d0.png

After it, accents are shifted to the left:
[image: accent_test_mpl_cm_master]
<
https://cloud.githubusercontent.com/assets/576258/9140292/ee9dbb3a-3d27-11e5-8fa9-12e87b192b57.png

I don't know much about parsers, so I don't really understand how this
can
happen from a cursory glance at mathtext.py. What other info do you need?

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/pull/4588#issuecomment-128752230>
.

—
Reply to this email directly or view it on GitHub
#4588 (comment)
.

[zblz]

The top one is from a test, the bottom is the one from issue #4462, and which is in tests as well since this PR:

r'$\ddot{o}\acute{e}\grave{e}\hat{O}\breve{\imath}\tilde{n}\vec{q}$'
r'$\Cup \Cap \dotplus \barwedge \doteq \doteqdot \rightharpoonup \ddots \leftharpoonup$'

Note as well that the mathtext test for the first one doesn't fail for me: maybe the accents don't have enough area to meet the threshold?

[WeatherGod]

re: accents, I bet you are right about that. We probably only test them on
normal size text, and so they aren't big enough to fail.

As for the parsing, what I think is really strange is that the \hat for the
'O' is at the midlevel, rather than raised, and the \breve is at the
midlevel as well. Makes me wonder if they are getting rendered completely
independently of the text they are operating upon?

On Fri, Aug 7, 2015 at 2:15 PM, Victor Zabalza notifications@github.com
wrote:

The top one is from a test, the bottom is the one from issue #4462
#4462, and which is in
tests as well since this PR:

r'$\ddot{o}\acute{e}\grave{e}\hat{O}\breve{\imath}\tilde{n}\vec{q}$'
r'$\Cup \Cap \dotplus \barwedge \doteq \doteqdot \rightharpoonup \ddots \leftharpoonup$'

Note as well that the mathtext test for the first one doesn't fail for me:
maybe the accents don't have enough area to meet the threshold?

—
Reply to this email directly or view it on GitHub
#4588 (comment)
.

[zblz]

It seems so: instead of being rendered in place and then shifted, it looks
as if the parser parses them independently of their associated character
and renders them before (assuming x-height for the base character?).
El dia 07/08/2015 19:35, "Benjamin Root" notifications@github.com va
escriure:

re: accents, I bet you are right about that. We probably only test them on
normal size text, and so they aren't big enough to fail.

As for the parsing, what I think is really strange is that the \hat for the
'O' is at the midlevel, rather than raised, and the \breve is at the
midlevel as well. Makes me wonder if they are getting rendered completely
independently of the text they are operating upon?

On Fri, Aug 7, 2015 at 2:15 PM, Victor Zabalza notifications@github.com
wrote:

The top one is from a test, the bottom is the one from issue #4462
#4462, and which is in
tests as well since this PR:

r'$\ddot{o}\acute{e}\grave{e}\hat{O}\breve{\imath}\tilde{n}\vec{q}$'
r'$\Cup \Cap \dotplus \barwedge \doteq \doteqdot \rightharpoonup \ddots
\leftharpoonup$'

Note as well that the mathtext test for the first one doesn't fail for
me:
maybe the accents don't have enough area to meet the threshold?

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/pull/4588#issuecomment-128785905>
.

—
Reply to this email directly or view it on GitHub
#4588 (comment)
.

[tacaswell]

Turns out this PR breaks the accent parsing, as in it never happens (and the comment in the code was correct). I am working on fixing this.

@zblz Thanks for catching this before we released!