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

[vtstydev]

On Tue, 30 Jan 2024 04:32:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 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 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?

This snippet works when application sets negative start point of imageable area of paper. 
I have tested it using 
` paper.setImageableArea(-50, -50, paper.getWidth(), paper.getHeight())`
LANDSCAPE oriented and REVERSE_LANDSCAPE oriented images printed with transparency aren't the same as the corresponded images printed with opacity. They are shifted in the opposite direction.

I suggest nobody tested printing with negative start point before. It's strange when start point is situated in the negative area in my opinion. Is there a sense to assume it may be used in such way?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17030#discussion_r1472340024