RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v10]

[Phil Race]

On Thu, 1 Feb 2024 11:32:17 GMT, vtstydev <duke at openjdk.org> wrote:

>> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper.
>
> vtstydev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Done requested fixes 2

> > Revert the changes to the test which limit the pages printed out.
> > The test MUST print all orientations and MUST always print both opaque and alpha
> > 95% of the point of this test is to ensure consistency across all cases and if it doesn't test them it is mostly pointless.
> 
> @prrace May I revert everything in the test that @prsadhuk requested here: [#17030 (comment)](https://github.com/openjdk/jdk/pull/17030#issuecomment-1920510837) or you prefer that I change only how acting test by default?

I mean by default, when run by a testing framework, the test should print all those pages.
This is a manual test. It will be run rarely so when it does get run it ought to be thorough.
Manual doesn't mean someone typing "java AlphaPrintingOffsets", it means when jtreg is told to run the "@key manual" tests.
Any test options would only come in to play only if a developer wants to run the test directly by hand and chooses them.
FWIW I doubt they'll be useful but no harm leaving them but I'm also fine with complete reversion.

PS those options also complicate the instructions to the user !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1935278887