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

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

[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.

[dipeshmsft]

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