Fix compatibility issue with MathTeXEngine

[Kolaru]

Description

Fixes the compatibility problem discussed in #1491 using the changes introduced in MathTeXEngine in Kolaru/MathTeXEngine.jl#58

I have given the same interface to TeXChar that FreeTypeAbstraction.FontExtent has. This means TeXChar can be used interchangeably with FontExtent, putting the full responsability to produce correct bounding boxes and positioning on MathTeXEngine without requiring additional special cases for LaTeXString in Makie.

I run the test locally and everything looked fine. Hopefully I did it correctly.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Edit: Looks like it may have been wise to wait for the registration of the new version of MathTeXEngine to be fully register before using it here >_<

[Kolaru]

The new version of MathTeXEngine has been merged to the registry so the CI can be retriggered (not sure if I can do it directly).

[Kolaru]

(so that the way to do it... thanks Simon ^^')

The tests fail because of one reference test:

Essentially the sum symbol got a little bit bigger and the big square root symbol changed.

To me it looks okay (but I don't quite understand how to update the reference or even if I need to do it manually).

So I would say it is ready for review.

[jaakkor2]

Square root looks much better now.

Y-label code would be better as
ylabel = L"x + y - \sin(x) × \tan(y) + \sqrt{2}",, i.e., backslash sin and tan.
https://github.com/JuliaPlots/Makie.jl/blob/432b8ab0b560e9acc0a2da4f1f0dddeadd3ae7c2/ReferenceTests/src/tests/text.jl#L257

[SimonDanisch]

Closes #1785 I suppose

[jkrumbiegel]

Why don't we use the same representation for both? It doesn't have to be FontExtent, but that is just a collection of a couple numbers anyway, so those should be extractable from TeXChar. Basically at the later point in the pipeline, I would like to not differentiate between different ways to generate text anymore.

[Kolaru]

Because I am lazy wanted to minimize changes for that PR.

That can totally be handled by the the GlyphCollection constructor and then stored in an unique way. I will look into it.

[jonas-schulze]

Would this help with #1560?

[SimonDanisch]

What's the state of this? Looks like most issues are addressed?
I'm seeing this in the reference image tests, which looks more like an improvement then a regression:

I measured the pixel distance from the border to the font, and before there is 1pixel difference between x/y, while now it's around 0.5 pixel difference, or something like that.

[Kolaru]

I think there is just a very minor change in the computation of the bounding box, but I haven't have time to go through all the references images to make sure I haven't break anything (I preferred to wait for the CI to make sure the tests are run correctly).

I will ping you once I have gone through everything.

[piever]

Sorry to bump here, but is this ready to be merged?

I suspect this may fix some problems in AlgebraOfGraphics: updating to new Makie somehow confuses the resolver, as the old MathTexEngine brings in an old version of RelocatableFolders, see here. I imagine upgrading to newer MathTexEngine would fix that.

[SimonDanisch]

@Kolaru happy to help getting this over the finish line!

[ffreyer]

I think one of my recent pr's messed up something with lines here. I'll try to merge master and fix it

[ffreyer]

Some nitpicking:

Fraction lines look slightly too far left to me:

The bounding box of integrals is a bit too tight:

[ffreyer]

I looked through the GLMakie failures. As far as I can tell they all failed because the bottom white space is slightly less, like in Simons gif. I don't think it's a problem...

[ffreyer]

height_insensitive_boundingbox_with_advance was using a ymax instead of a height. With that fixed:

However using ink_bounding_box gives even tighter bounding box, so I switched to that: (This also works for normal text)

[SimonDanisch]

Nice, thank you! :)
Looks good so far, besides this one, which seems a bit tight around the x label:

[ffreyer]

Failures (in GLMakie) are still related to bounding box changes. Most are irrelevant but some are worth mentioning:

It seems like something changes about axis limits in this test:

Latex ticks (and latex labels) are very tight now: (Though you might count that as a problem of normal text, since that seems to use more space than it technically should)

[ffreyer]

I changed text alignment to be based on character sizes rather than font sizes. As far as I can tell this makes the vertical alignment of normal text gap-less now. I tweaked the gaps in Axis to get back to how they are on master. There is probably a bunch more that need a ~2px bump because of these changes though...

[SimonDanisch]

@ffreyer Could they be more accurate now, so that 7f0 is actually closer to the padding we want?

[SimonDanisch]

What's with this?

Reference:

[ffreyer]

Could they be more accurate now, so that 7f0 is actually closer to the padding we want?

The left/right alignment still has a gap between text.position[] and the start/end of a character. I think that's true for both types of strings though, so I didn't try to change it here. I changed the ylabelpadding because the rotated label lost about 2px with the change in vertical alignment.

What's with this?

The tallest character starts/ends at the y value of the given text position now. 3 of those share that position, so they touch now. Before it was based on the height of the font, which I guess means the tallest character in the font?

[ffreyer]

I think these tight alignment changes are also part of #1847 (but probably implemented differently) Maybe we can merge the prs?

[jkrumbiegel]

The reason that I don't use the exact character bounding boxes anywhere else are that when you animate a title for example, you don't want it to jitter up and down when you change an f to a g and I use the advance values for left/right alignment because otherwise left-aligned text for example looks more "ragged". It is a bit more difficult with MathTeXEngine to choose a good behavior because the ascender / descender settings of the font used seem pretty large.

[jkrumbiegel]

Obsolete via #1952

[SimonDanisch]

Thanks everyone :) Really happy to get this finally merged :)