fix: calculate advance width for ch correctly

[aschmitz]

The "ch" value uses the advance width - not the ink width - of the "0" character.

This gets us closer to the results from line_break's line_size method, the only thing missing would be adding in the value of style['letter_spacing']. This method already avoids touching that because it could cause recursion, but it's not clear that it should be included anyway: the relevant spec seems to say only:

The advance measure of a glyph depends on writing-mode and text-orientation as well as font settings, text-transform, and any other properties that affect glyph selection or orientation.

(emphasis added)

Which would seem to indicate that perhaps we don't actually want to care about the letter spacing purely as part of the ch measurement.

[aschmitz]

Apologies for this and #1607, clearly I should have done more testing before pushing 4833bf6.

With this commit, my render tests with documents that use both ex and ch generate pixel-identical PDFs to 5ad3b1d. (They didn't without both relevant PRs.)

[liZe]

The "ch" value uses the advance width - not the ink width - of the "0" character.

Funny to note that we shared this behavior with Internet Explorer (rest in peace).

Apologies for this and #1607, clearly I should have done more testing before pushing 4833bf6.

I should have too before merging!

With this commit, my render tests with documents that use both ex and ch generate pixel-identical PDFs to 5ad3b1d. (They didn't without both relevant PRs.)

That’s good to know.