PrintSettings differ between 3.2704 and 3.3325

[Phylanx]

Hello!

We upgraded our JCEF implementation lately from 3.2704 to 3.3325 and most things worked fine.
One problem we have is, that it seems that the handling of the printsettings seems to have changed.
Now we have problems with our "fit in page" - "fix", see viewtopic.php?f=17&t=14789

In short: borderless PDFs (with content bigger than the printable area) where cut when printing. we implemented an additional 5% shrink (page.shrink_factor();) in printed_document_win.cc and fixed negative printing offsets.

Our automatic tests are printing such PDFs to with the PDFCreator and test if the shrink percentage is working.
Results:
With 3.2704 the shrink percentage works, the PDF is shrinked.
The original shrink factor is modified and the resulting PDF is as expected.
Also see our additional implemented logging:
[4728:17936:1001/154752:INFO:printed_document_win.cc(67)] MPA_LINZ_Chromium_Patch: printed_document_win.cc; Using shrink factor 0.161631 instead of 0.153934

With 3.3325 the shrink percentage is used, but has no effect.
The resulting PDF is an unmodified copy of the original PDF.
Also see our additional implemented logging:
[16396:10364:1001/153029.114:INFO:printed_document_win.cc(67)] MPA_LINZ_Chromium_Patch: printed_document_win.cc; Using shrink factor 1.05 instead of 1

The great difference I see is that the page.shrink_factor() is 1 instead of 0.153934; where does that value come from?

We have seen this problem only on some virtual PrintToPDF Printers, we haven't seen this behavior on physical printers until now.

[Phylanx]

I guess I've found something.

The code responsible for calculating the correct scale_factor lies here:
https://cs.chromium.org/chromium/src/ch ... &g=0&l=120

In our use cases the postcript parameter decides if the "normal" numbers are used or simply "1" is passed.
That means: If the generated page document is no postscript, the scale_factor is calculated and our shrink works.
With PostScript it does not.

I'll have a further down look on that, just wanted to keep the thread on track.

[Phylanx]

Our final solution is to disable the postscript printing feature:

.\chromium\src\chrome\common\chrome_features.cc

old:
const base::Feature kDisablePostScriptPrinting{
"DisablePostScriptPrinting", base::FEATURE_DISABLED_BY_DEFAULT};

=> new:
const base::Feature kDisablePostScriptPrinting{
"DisablePostScriptPrinting", base::FEATURE_ENABLED_BY_DEFAULT};

I'm aware that this is not a "nice" solution, it's a hack for our hack, but we need it as long as the custom chromium print dialog with the "fit in page" option isn't available for windows.

[magreenblatt]

Our final solution is to disable the postscript printing feature:

.\chromium\src\chrome\common\chrome_features.cc

old:
const base::Feature kDisablePostScriptPrinting{
"DisablePostScriptPrinting", base::FEATURE_DISABLED_BY_DEFAULT};

=> new:
const base::Feature kDisablePostScriptPrinting{
"DisablePostScriptPrinting", base::FEATURE_ENABLED_BY_DEFAULT};

I'm aware that this is not a "nice" solution, it's a hack for our hack, but we need it as long as the custom chromium print dialog with the "fit in page" option isn't available for windows.

You should be able to make this change via the command-line with ‘—enable-features=DisablePostScriptPrinting’ instead of changing the code in chrome_features.cc.

[Phylanx]

Thanks Marshall for the info.
Unfortunatly too late, the code is built, submitted and working.

Changing the solution would mean running through our whole releasing procedure again (change, tests, build, test, ...) where I don't get the time for that

But I'll keep that in mind and change it when I have to touch code again!