1962816 - Print output layout is broken, when printing "writing-mode: vertical-rl" content to an actual printer (i.e. not the built-in Save-to-PDF print target)

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Alice0775 White]

Attachment: testcase.html

STR:

1. Open attached testcase.html
2. Print, e.g. Microsoft Print to PDF

Actual results:
The print preview appears to be correct. However, the print result is completely corrupted.

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=d735e197d708d85d9b7e7cb1ea3609bdc4f27bd6&tochange=7387be4b195f3f266410d8faafbaf80f8176e293

Comment 1

[Alice0775 White]

Attachment: print_output.pdf

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

:jfkthame, since you are the author of the regressor, bug 739096, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Daniel Holbert [:dholbert]]

I can reproduce, when printing the testcase to the "Microsoft Print to PDF" print target.
I can also reproduce when printing the testcase to an actual printer (Brother HL-2280DW).

But for whatever reason, I cannot reproduce when printing to our built-in Save-to-PDF print backend. So that's sort-of a workaround, I suppose. (i.e. you can avoid this bug by first printing to the Save-to-PDF backend, and then printing the resulting PDF (whether from Firefox or any PDF viewer) to the print target where you really want to print)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (from dupe bug)

Here's a testcase from dupe bug 1962676. This testcase has "This is a test" written vertically (with "T" at the top), but Alice0775 White posted a printed result https://bugzilla.mozilla.org/attachment.cgi?id=9481160 which shows the letters placed in the reverse order, with "T" at the bottom.

Comment 6

[Jonathan Kew [:jfkthame]]

This isn't unique to vertical writing modes; a similar problem can be reproduced with horizontal text where there are glyphs that require a vertical offset, such as stacked accent glyphs:

data:text/html;charset=utf-8,<div style="margin:1in;font:40px times new roman">foö́̈̂̈̃̈̀ba̠̣̰̱r

"Printing" this via the Microsoft Print to PDF driver, or to a physical printer on Windows, will render the stacked accents incorrectly.

I think I know where to fix this... testing a patch locally.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1962816 - Invert sign of delta-y when computing glyph advances for ExtTextOutW, because the GDI coordinate system is inverted. r=#gfx-reviewers

We used to have a sign-inversion like this in our cairo backend code:

https://searchfox.org/mozilla-central/rev/0b6a214452a91745638b03d71da86ebe45e34efe/gfx/cairo/cairo/src/cairo-win32-surface.c#1892-1893

This was previously fixed (by me!) back in bug 454098, but in the
process of updating cairo the change got lost as the code had moved
around and so our old patch file no longer applied.

(I'll see if I can get the standalone test program from that bug
working again, and file the issue upstream.)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ed26c5e737c7
https://hg.mozilla.org/integration/autoland/rev/109c097291f5
Invert sign of delta-y when computing glyph advances for ExtTextOutW, because the GDI coordinate system is inverted. r=gfx-reviewers,jrmuizel

Comment 9

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/109c097291f5

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 11

[Jonathan Kew [:jfkthame]]

This has been broken for quite a while, but given how trivial and low-risk the patch is, I think we should uplift it to esr140 so that Windows users on ESR get the fix rather than remaining in the broken state long-term.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1962816 - Invert sign of delta-y when computing glyph advances for ExtTextOutW, because the GDI coordinate system is inverted. r=#gfx-reviewers

We used to have a sign-inversion like this in our cairo backend code:

https://searchfox.org/mozilla-central/rev/0b6a214452a91745638b03d71da86ebe45e34efe/gfx/cairo/cairo/src/cairo-win32-surface.c#1892-1893

This was previously fixed (by me!) back in bug 454098, but in the
process of updating cairo the change got lost as the code had moved
around and so our old patch file no longer applied.

(I'll see if I can get the standalone test program from that bug
working again, and file the issue upstream.)

Original Revision: https://phabricator.services.mozilla.com/D254737

Comment 13

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Vertical Chinese/Japanese text (and some more complex horizontal scripts) prints incorrectly on Windows
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On Windows, load testcases in the bug, and print (to an actual printer, or Microsoft Print to PDF -- NOT built-in Save To PDF destination)
• Risk associated with taking this patch: minimal
• Explanation of risk level: Restores a trivial fix in the cairo windows backend that we previously shipped for a number of years
• String changes made/needed: none
• Is Android affected?: no

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/2c845a484b45

Comment 15

[Jonathan Kew [:jfkthame]]

FTR, I've opened https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/629 to try and get this merged upstream.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox141 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1962816 - Invert sign of delta-y when computing glyph advances for ExtTextOutW, because the GDI coordinate system is inverted. r=#gfx-reviewers

We used to have a sign-inversion like this in our cairo backend code:

https://searchfox.org/mozilla-central/rev/0b6a214452a91745638b03d71da86ebe45e34efe/gfx/cairo/cairo/src/cairo-win32-surface.c#1892-1893

This was previously fixed (by me!) back in bug 454098, but in the
process of updating cairo the change got lost as the code had moved
around and so our old patch file no longer applied.

(I'll see if I can get the standalone test program from that bug
working again, and file the issue upstream.)

Original Revision: https://phabricator.services.mozilla.com/D254737

Comment 18

[Jonathan Kew [:jfkthame]]

(See comment 13 for uplift request form.)

Comment 19

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/d84b956d41d2
https://hg.mozilla.org/releases/mozilla-beta/rev/0f93554b9e71

Comment 20

[Bogdan Maris, Desktop Test Engineering]

Reproduced the initial issue using both Testcases from this bug on an old Nightly build before the fix (2025-04-25). Verified that using the latest Nightly 142.0a1 build, latest Beta 141.0b3 and ESR 140 build from treeherder both Microsoft Print to PDF and Save to PDF work as expected, as well as using a physical printer.