Affected versions

• 84.0.2 (20210105180113)
• 85.0b6 (20210107185759)
• 86.0a1 (20210108094818)

Affected platforms

• Windows 10x64

Preconditions

• print.tab_modal.enabled:true

Steps to reproduce

1. Open Firefox and http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf.
2. Click on the Hamburger menu and select the print option.
3. Select Save to Pdf as Destination and save.
4. Open the saved pdf and observe the Favourite Color section.

Expected result

• Text is displayed as expected.

Actual result

• Text is slightly cut off on the upper side. On longer color names like Brown/Orange, the cut-off is more visible.

Regression range

• I will search for one ASAP.

Notes

• Attached a screenshot.

Hello! I tried searching for a regression range but it seems that the issue is reproducing since the implementation of the Save to PDF option. Since this is reproducing only with Save to PDF I think this is not a regression. Here are the mozregression results.
Last good revision: 94982363dfa4b5bde758cf1442a9166dc07c16fb
First bad revision: d6ae04588d3425c058afc56a47ba5345167ea04b
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=94982363dfa4b5bde758cf1442a9166dc07c16fb&tochange=d6ae04588d3425c058afc56a47ba5345167ea04b

Bug 1685696 has a (much larger) PDF that reportedly reproduces this with some text that's not in a dropdown menu. It also happens with Safe-to-PDF being used on a PDF file, so I think it's the same core issue. The testcase there is https://www.cambridgeenglish.org/images/153310-movers-sample-papers-volume-2.pdf ; and that bug report is Win7-only, but that might be due to particular peculiarities of the text/fonts in that PDF and the particular font metrics on Win7 that make it more susceptible to what I'm guessing is a more general bug (given that we have this similar report on Win10)

For archival purposes, here's the PDF that's linked in comment 0 here (just in case its hosting server drops offline at some point).

I can't reproduce any issues here, using my current Nightly on Linux, for what it's worth. So the issues here may be Windows-only (or font-specific in a way that makes them Windows-only for these particular testcases).

Alexandru, would you mind attaching the final broken PDF file that you get when you follow the steps-to-reproduce?

(In reply to Daniel Holbert [:dholbert] from comment #6)

I can't reproduce any issues here, using my current Nightly on Linux, for what it's worth. So the issues here may be Windows-only (or font-specific in a way that makes them Windows-only for these particular testcases).

Alexandru, would you mind attaching the final broken PDF file that you get when you follow the steps-to-reproduce?

Yes, from what I see this is Windows only issue. At least for this particular test case. This is the PDF saved on Windows 10x64 with Firefox 86.0a1 (20210111215143). If more information is needed please let me know.

Attaching one with initial Orange selection as well

Thanks! Last question -- do you see this same clipping when you print to an actual printer, too? (using Firefox, using a printer as the print-target rather than using Save-to-PDF)

If so, this might be related to bug 1349616 (thanks to csasca for noticing that earlier bug report).

Actually I was able to answer my own question. I can reproduce the clipped text in testcase 1, on Win10, after printing it to the "Save to PDF" print target; but I don't get any clipping if I print it to a real printer, or to "Microsoft Print to PDF".

So this does seem at least somewhat specific to this "Save to PDF" print target.