Printing from WPF is leaving random small spaces in the text when using Arial or Calibri fonts

[campeters]

Description

When printing in WPF, the graphics engine is inserting small spaces within words. For instance, the French word 'fonctions' is printed either as 'fonction s' or 'fo nctions' depending on where the word appears within the other text.

Reproduction Steps

public void PrintItAll()
        {
            var printDialog = new PrintDialog();
            if (printDialog.ShowDialog() == true)
            {
                var fontFamily = new FontFamily("Arial");
                var printme = new TextBlock {
                    FontSize = 11, FontFamily = fontFamily, Width = 800, TextWrapping = TextWrapping.Wrap,
                    Text = "L'autre personne était incapable de prendre soin des enfants en raison d'une déficience des fonctions physiques ou mentales qui l'a obligée, durant une période d'au moins deux semaines, à garder le lit, à se déplacer en fauteuil roulant ou à recevoir des soins dans un hôpital ou un établissement semblable. Joignez un certificat du médecin traitant qui confirme la nature et la durée de la déficience."
                };
                printDialog.PrintVisual(printme, "Test Print");
            }
        }

Reproduction repository: https://github.com/campeters/Wpf-Print-Font-Issue

Expected behavior

The text should print correctly without extra spaces.

Actual behavior

The following file shows a space between 'fonction' and the 's'. It should be a single french word 'fonctions'

Test Print.pdf

Regression?

This code works correctly in dot net framework and it also seems to work correctly in .net 5.

Known Workarounds

None.

Impact

This bug impacts the quality of PDF and print files generated from WPF programs using the 'Arial' or 'Calibri' fonts. Some fonts work correctly. However, the filing of some government forms require that only 'Arial' be used.

Configuration

This bug occurs in .net 6, confirmed in 6.0.11 and 6.0.13 and .net 7. It does not appear to be specific to the configuration. It happens on Windows 10 and Windows 11.

The exact same code works correctly in .net framework 4.8.1

Other information

No response

[miloush]

Interesting, net48 blue, net7 red overlaid:

Looks like expected in a FixedDocument in DocumentViewer, but printing it to pdf has the same issue.

[dipeshmsft]

@miloush @campeters, I am not sure yet but this issue looks like the effect of this fix #6295
In the attached bug, you will see screenshots related to the problem.

The main issue here comes from the fact that when we print to XPS ( pdf here ) the 'advance width' values are converted from double to int and therefore after a few characters the difference between what is displayed on the screen and when it is printed became significant. Therefore, to mitigate this, we cumulated the error of conversion and update the next 'advance width' value by +/-1 when the cumulated error exceeded +/-1.

[miloush]

Yes it looks like a rounding error (though I would expect it to repeat on the right side). The solution in #6295 might even lead to catastrophic cancellation. It would be better to keep track of the accumulated advance widths rather than errors.

[campeters]

@dipeshmsft @miloush - I can confirm that reversing #6295 fixes the rendering problem in our app.

[campeters]

Is there a repo that contains an example of the rendering issue shown here? #6525 If so, I could try to find a fix for my issue that does not break that one...

[dipeshmsft]

I can find a sample repo for this issue. I will get back to you with the sample application.

[dipeshmsft]

Hey @campeters, here is the sample app GlyphRunIssue.zip
to repro the behavior before the fix.

[campeters]

Here is a repo that shows both of the issues:

https://github.com/campeters/GlyphRunIssue

In .net 5, the text renders correctly. In .net 6, the glyphs render correctly.

[campeters]

@miloush / @dipeshmsft - I've reviewed this in more detail and the advanceErrorRounding is not the root of the problem. Somewhere upstream of the GlyphSerializer (maybe the DrawingContextFlattener), the GlyphRuns are separated into groups of no more than 100 characters. Within the 100 character glyph run, the spacing is correct. However, when the drawing caret is advanced to start the next 100 character glyph run, the error correction is not taken into account, leaving an extra space (or possibly two characters squished together). I'm going to look further, but if you have some idea where in the code the glyph runs are separated we could correct the root cause of this issue.

[miloush]

The ±100 character chopping happens in MS.Internal.TextFormatting.TextStore, resp. MS.Internal.TextFormatting.TextRunCacheImp.FetchTextRun, but I don't think it is very relevant. If you turn off the rounding completely, it renders as expected. Fix the rounding and you should be good.

[miloush]

OK while technically true, it is not a simple algorithmical issue, there seems to be an actual bug in what is rounded. I suspect the advance widths from shaping and from font can differ in floating precision but not integer precision. In such case, the error from shaping is taken but the font one should be used. There is also question about what precision does the "font width" use in XPS. I will have a look.

[campeters]

I've messed around with the code in TextStore and I can improve the rendering by changing FetchTextRun so that it prefers breaking on a space. That way the extra fraction of a space is not noticeable.

However, I suspect you are right... there is a a difference in the precision XPS uses for font width and what WPF uses when it does the layout.