[Discussion in progress] Round all the calculations to whole pixels

[ForNeVeR]

While investigating #50 I've found that we have small rounding issues everywhere. To fix them, I had to introduce rounding in every Draw method.

Obviously we could add a smarter solution, but let's discuss that in principle at first.

The outcome is that the formulae are not so blurry. Check out these screenshots:
Before:

After:

Unfortunately, now we have small troubles (on some of the scale levels) when connecting part of square root tail with the rest of the radical line. Honestly said, earlier we had small issues there, but now we have huge noticeable gap. The following examples were taken with Scale = 21.0:

Before:

After:

That last issue is cleanly a regression, so I'm not sure if we want to merge this PR as-is. Let's discuss! @torfranz, I welcome you to take a look, too.

[alexreg]

Hmm. I can see there was already a minute issue before these modifications, like you say. Did you figure out the cause of this (roughly speaking, even)?

[alexreg]

I have no idea how to solve this problem elegantly right now (perhaps the hour is to blame!)... but I'm not a great fan of the current solution, to be honest. Did you consider any other approaches?

[ForNeVeR]

@alexreg thanks, that was a good question. I've struggled a bit around SVG rendering code, and found that the SVG image rendered by our code had no flaws. So, I've tried to replace the code in VerticalBox.Draw with a call to RenderGeometry:

    internal class VerticalBox : Box
    {
        // ...
        public override void Draw(DrawingContext drawingContext, double scale, double x, double y)
        {
            base.Draw(drawingContext, scale, x, y);

            var g = new GeometryGroup();
            RenderGeometry(g, scale, x, y);
            drawingContext.DrawGeometry(Brushes.Black, new Pen(), g);
        }
        // ...
    }

And here's what I got:

The radical line is now absolutely straight in any scale, but

1. the vertical line in the radical sign have noticeable gaps between its composable parts
2. the font antialiasing was completely disabled, because WPF now renders actual geometry instead of font characters (although I'm not sure that's a bad thing; the result without ClearType actually looks a bit clearer to me)

I think that's a viable solution, but we need more work on it:

1. fix these gaps on the vertical line
2. try to scope the change only to the radical sign and surrounding lines (everything else should stay as-is)

We need also think more about switching the whole render to DrawGeometry instead of DrawGlyphRun. Probably that will be the best solution.

[alexreg]

Ahh, those damned gaps in the line — I actually remember them from my testing 6 years ago!

I think that turning off ClearType would perhaps be a good idea, since TeX is not designer to work with it.

[alexreg]

Just had a little play around, and no idea what's causing those gaps! If I couldn't solve it back then... do have a go, and let me know how you get on though.

[torfranz]

Hi,
I tried the 2 branches 50-blur and 50-blur-alternate against the master and for my particular case 50-blur was the best option so far. My formulas are rather simple compared to the example formula so I can't really tell what will be best going forward. Maybe some RenderPath property as long as there is no best universal solution? Thanks for all your effort so far, I see this will probably not be easily solved.

[ForNeVeR]

Idea from #66: compare our fonts with the ones from LaTeXMath — probably the guys there have already solved the issue.

[alexreg]

Yep. If using their fonts doesn't work, and there are no obvious tricks in their code, perhaps we can even point them to our issue, and see if they recognise the problem from their past work.

[gsomix]

Latest 50-blur-alternate branch.

[ForNeVeR]

As we ascertained with @gsomix, now that branch looks nice, but still blurred at some of the scale levels. Probably we'll need to merge it with (at least some of) the changes in bugfix/50-blur.

[alexreg]

Very good. Yeah, I'll let you test that out. If we could be clear about what changes we're making to reduce blurriness (and make the minimal number possible), then that would be great. Would be happy to review a PR then.

[ForNeVeR]

Yep. We're slowly making progress in this issue, it's not yet ready for review and merging.

[ForNeVeR]

I'm closing the PR and deleting the branches bugfix/50-blur and bugfix/50-blur-alternate, because issue #50 was solved by #71.

[alexreg]

Small issue, can probably be committed directly: change default formula in example to:

L = \int_a^b \sqrt[4]{ \left| \sum_{i,j=1}^ng_{ij}\left(\gamma(t)\right) \left[\frac{d}{dt}x^i\circ\gamma(t) \right] \left{\frac{d}{dt}x^j\circ\gamma(t) \right} \right|}dt

[ForNeVeR]

@alexreg, done that!