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

[Prasanta Sadhukhan]

On Mon, 29 Jan 2024 06:56:58 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 one additional commit since the last revision:
> 
>   Fix header and imports section in AlphaPrintingOffsets

src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2399:

> 2397:                      */
> 2398:                     bandGraphics.setTransform(uniformTransform);
> 2399:                     bandGraphics.translate(-deviceAddressableX,deviceAddressableY);

a <space> is needed between 2 arguments as per coding guidelines..

src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2424:

> 2422:                         int bandX = deviceLeft;
> 2423:                         if (bandX < 0) {
> 2424:                             bandGraphics.translate(bandX/xScale,0);

Did we test this path where another translate is being done on the same object after it is done in l2399?

test/jdk/java/awt/print/PrinterJob/ImagePrinting/AlphaPrintingOffsets.java line 73:

> 71:             System.out.println("Printer not configured or available."
> 72:                     + " Test cannot continue.");
> 73:             PassFailJFrame.forcePass();

I guess it is now being preferred to throw jtreg.SkippedException instead of forcePass for printers not available scenarios?!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1470578878
PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1470578522
PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1470579615