RFR: 8307246 : Printing: banded raster path doesn't account for device offset values [v7]
Prasanta Sadhukhan
psadhukhan at openjdk.org
Tue Jan 30 04:38:42 UTC 2024
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
More information about the client-libs-dev
mailing list