[Bug]: Incorrect mathtext rendering of r"$\|$" with default (dejavu) math fontfamily

[anntzer]

Bug summary

r"$\|$" should render as a double vertical bar, which it does with usetex or with math_fontfamily="cm", but not with the default "dejavusans" math_fontfamily.

Code for reproduction

s = r"single$|$ double$\|$"
figtext(.5, .7, s); figtext(.5, .6, s, math_fontfamily="cm"); figtext(.5, .5, s, usetex=True)

Actual outcome

Expected outcome

Double vertical bar in the first line too.

Additional information

No response

Operating system

arch

Matplotlib Version

3.6.0.dev2423+gd0bef3b3d7

Matplotlib Backend

qt5agg

Python version

3.10

Jupyter version

ENOSUCHLIB

Installation

git checkout

[oscargus]

\Vert seems to work though.

[oscargus]

It is just to change

matplotlib/lib/matplotlib/_mathtext_data.py

Line 529 in ee7c4a0

'|' : 124,

to

    '|'                        : 8214,

But the base line images are incorrect:
https://github.com/matplotlib/matplotlib/blob/main/lib/matplotlib/tests/baseline_images/test_mathtext/mathtext_dejavusans_68.png

matplotlib/lib/matplotlib/tests/test_mathtext.py

Line 103 in ee7c4a0

r"$\left\Vert a \right\Vert \left\vert b \right\vert \left| a \right| \left\| b\right\| \Vert a \Vert \vert b \vert$",

The second b should have double vertical bars around it.

[oscargus]

And the problem holds for any other font than cm it seems.

[anntzer]

It would seem reasonable to fix the baseline image (preferably after #22881, as usual: here again, what really matters is that the right glyph gets embedded, not the exact glyph-to-path conversion).

(I haven't checked that the proposed fix works, but it doesn't have to be complicated indeed.)

[oscargus]

I only checked the png output visually. The svg output actually didn't error I realize, so I should probably check that (pdf did error though). Primary problem of fixing it is right now that some of the other pngs error on my machine, so not sure it is a good idea to upload images with slightly off fonts (RMS in the range 1 to 3...).

[oscargus]

And that is because on my Windows machine, the svg tests are not executed. But I can confirm that the PDFs are now correct.

[anntzer]

Do you have inkscape installed? If so, svg tests should be executed (if not, please open a separate bug and let's fix that...).

[oscargus]

I have it installed, but, as so often for Windows, not in the PATH. I thought it could be related to something like that. Will try to sort it out.

[oscargus]

Now it breaks SVG as well, so as far as I call tell, it seems to fully work to simply change that.

[anntzer]

1. In the Inkscape installer, is there an option like "add inkscape to PATH"? If so easiest would be to just document that it needs to be installed in this manner.
2. Otherwise, is Inkscape registered in the registry App Paths subkey (https://docs.microsoft.com/en-us/windows/win32/shell/app-registration#using-the-app-paths-subkey, see also the difference between CreateProcess and ShellExecute)? If so we could read it ourselves to get inkscape's full path. (Note that this is only with inkscape>1.1 (https://gitlab.com/inkscape/inkscape/-/merge_requests/2859) but it seems OK to require that.)

Anyways, this should probably be moved to a separate issue to keep track of it.

[oscargus]

1. In the Inkscape installer, is there an option like "add inkscape to PATH"?

Yes. I just installed 1.2 to check it, but got an error saying that the PATH was too long to modify. I solved it earlier by simply adding the correct path though.

(I do not think there needs to be an issue for me being lazy/ignorant, or it would be a pretty long issue...)

[anntzer]

Well, we should at least document that inkscape needs to be installed with that option checked, as that seems like a useful piece of info for other newcomers...

[oscargus]

Maybe related. Today I realized that autoscaling of | and \| does not work properly.

plt.text(0.05, 0.05, r'$\left|\frac{\frac{3}{2}}{1}\right\|$    $\left(\frac{\frac{3}{2}}{1}\right)$')

'cm' seems to work though:

Edit: and I realize that my change above could work, but then there are no alternatives so AutoHeightChar breaks on init as char is not set (as alternatives is empty, I assume). If you put 8124 instead of 8214...