[OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y

[prasanta sadhukhan]

Hi Phil,

Actually, the test program does 3 subtests
1. negative y
     we get ix=12, iy=12, iw=571, ih=817 in Margins.java#print() where 
we do System.out.println("ix="+ix+" iy="+iy+" iw="+iw+" ih="+ih);
which is correctly getting hardware margin and not Java default 1" margin

2. printable height more than paper height
     we get ix=12, iy=12, iw=571, ih=817
which is correctly getting hardware margin and not Java default 1" margin

3. negative width
     we get ix=72, iy=72, iw=451, ih=697
which is not correct as we get 1" margin and not hardware margin

With webrev.01, I am getting ix=12, iy=12, iw=571, ih=817 ie, correct 
hardware margin same as the other 2 subtests . *Is it not correct?*

I guess your suggested change wants me to do the below but I am not sure 
how to get hardware margin? Can you please suggest how to constrain 
iw/ih with ix/iy?

686         if (ix < 0) ix = 0f; if (iy < 0) iy = 0f;
687	    float left = (ix > 0) ? ix : 1.0f; // take valid ix or 1" ??? how will I get hardware margin??
688         float top = (iy > 0 ) ? iy : 1.0f; // take valid iy or 1"
  689 if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (left*2.0f);
690 if (ih <= 0) ih = (float)(page.getPaper().getHeight()/DPI) - (top*2.0f);

Regards
Prasanta
On 5/31/2016 10:12 PM, Phil Race wrote:
> Well ... few printers can print on the entire paper. Photo printers are
> the ones that can do this. So Paper dimension minus the "hardware 
> margins"
> are the maximum imageable width.
> And then supposing imageable x/y is some perfectly reasonable value 
> like 1" each
> then you've set iw/ih such that even a printer with zero hardware 
> margins has
> an imageable area that goes off the bottom and right off the paper.
>
> More reasonable would be to constrain iw/ih such that they work with the
> requested ix/iy - assuming they are also valid.
>
> If all else fails then just using the "default" set of values as if 
> the application
> had not set any values would be better.
>
> -phil.
>
> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote:
>> Hi Phil,
>>
>> I got it rectified.
>>
>> Please find the modified webrev
>>
>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/
>>
>> Regarding using entire width/height pf paper, I thought since 
>> imageable width/height is invalid we should make the entire paper as 
>> the imageable area.For invalid x,y we were making it to paper's 
>> top/left.
>> Else what option do we have, should we calculate 
>> width[height]=abs(image[width][height]) instead?
>>
>> Regards
>> Prasanta
>> On 5/25/2016 10:07 PM, Philip Race wrote:
>>> It seems to me that you are using the wrong units.
>>> You have not divided by DPI to get inches.
>>>
>>> Also I am not sure that the *entire* width/height of the paper is 
>>> what you want here
>>> but that is secondary to the first issue
>>>
>>> -phil
>>>
>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for jdk9 which is a continuation of the fix of 
>>>> JDK-6543815.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/
>>>>
>>>> 6543815 fix resets the x,y to 0 if they are negative before 
>>>> creating a MediaPrintableArea and the platform replaces it with 
>>>> hardware margins when printing.
>>>> This works only if x/y is negative.
>>>> But, If either width/height is negative alongwith x or y, then the 
>>>> margin is set to the java def 1 inch margin and not hardware margins.
>>>>
>>>> This is because width/height -ve results in IAE in 
>>>> MediaPrintableArea constructor and so values are ignored.
>>>> Added a check for -ve width/height to make sure width/height are 
>>>> set to minimum paper width/height.
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160601/cac73ebd/attachment.html>