[OpenJDK 2D-Dev] [8] Review request for 8007642: Media Names on Java Print Do Not Match the Printer's and Confuse Users

Jennifer Godinez jennifer.godinez at oracle.com
Fri Jun 21 16:23:03 UTC 2013 

Approved.

Jennifer

On 4/23/13 8:19 AM, Anton Litvinov wrote:
> Hello Jennifer,
>
> Thank you for clarification of your situation with JVM crash. I am 
> very glad to know that it was not caused by the fix and that you 
> managed to evaluate it. I tried to test the fix with the printer 
> driver "Brother MFC-J6710DW", which you specified in your previous 
> e-mail. I also was able to reproduce the situation with absence of the 
> media size "Ledger (Short Grain)(11 x 17 in)" in Java Page Setup 
> dialog, but debugging showed that this media size was displayed as 
> "Ledger" and "Ledger (11 x 17 in)" was considered as "Tabloid", 
> because its paper ID equaled "3", which is really "Tabloid". So, 
> probably, other native applications, whose page setup dialogs show 
> "Ledger (11 x 17 in)" instead of "Tabloid", simply print out media 
> size names returned by the driver, therefore I suppose that exactly 
> this media size is problematic because of the driver, which supplies 
> either the wrong paper ID or the wrong paper name. I created an 
> improved second version of the fix. Could you please review it.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.01
>
> Differences between this fix and its previous version are the following:
>
> 1. Static initialization block of Win32PrintService class was removed, 
> because its internal call
>
>     86         Class c = Win32MediaSize.class;
>
> did not lead to initialization of the static variable "predefMedia" 
> from a static initialization block of Win32MediaSize class. Such 
> situation is the reason of constant returning of null values from
>
>     623           msn = findMatchingMediaSizeNameMM(wid, ht);
>
> for each first iteration of the for loop in 
> "Win32PrintService.getMediaSizes" method. As a solution for this 
> problem "predefMedia" started being initialized by a direct call to 
> the new "Win32MediaSize.getPredefMedia" method, which guarantees that 
> before its execution the static initialization block of Win32MediaSize 
> class is already executed.
>
> 2. Additional changes in the method "Win32PrintService.initMedia" 
> guarantee that a media size name provided by the printer's driver is 
> always added to "msnList" local variable, if a paper ID does not match 
> with any paper ID predefined in JDK (the call 
> "findWin32Media(((Integer)idList.get(i)).intValue());"). This change 
> makes it possible to display "Ledger (Short Grain)(11 x 17 in)" media 
> size with the driver "Brother MFC-J6710DW". So in certain cases this 
> fix leads to displaying of 2 media size names for one media size: 1 
> media size name registered in JDK, whose media size matches with this 
> media size,  1 new media size name constructed from a string returned 
> by the driver. Testing in my local environment with all earlier 
> mentioned printers showed that cases of presence of such pairs of 
> media size names are very rare, while they help users to find the 
> required media sizes in Java Page Setup Dialog.
>
> Thank you,
> Anton
>
> On 4/20/2013 1:39 AM, Jennifer Godinez wrote:
>> Hi Anton,
>>
>> I apologize that the cause of the crash is specific to my system. I 
>> re-cloned a fresh copy and did not see the crash anymore.  The fix 
>> works but I have concern that mixing media size names with JDK 
>> predefined names with printer driver is still confusing for the 
>> user.  For one, I was able to find a driver,  Brother MFC-J6710, 
>> wherein it has 4 types of Ledgers (Ledger, Ledger Short Grain, Ledger 
>> Borderless, and Ledger Borderless/ShortGrain) .  In JDK, it is 
>> showing, Ledger, Tabloid, Ledger Borderless, and Ledger 
>> Borderless/ShortGrain.  I think our use of Tabloid is still not 
>> right.  I'm leaning towards either changing all the names but this is 
>> up for discussion.
>>
>> Jennifer
>>
>> On 4/19/2013 9:23 AM, Anton Litvinov wrote:
>>> Hello Jennifer,
>>>
>>> I am sorry, but I cannot confirm existence of such a crash, because 
>>> in my local environment I do not experience any unchecked Java 
>>> exceptions and JVM crashes. Today I have made a fresh clone of all 
>>> workspaces from the repository 
>>> (http://hg.openjdk.java.net/jdk8/jdk8), have applied this fix and 
>>> have compiled the JDK 8. Also, to be on the safe side, PrimoPDF 
>>> printer has been reinstalled with the latest version available for 
>>> downloading from the web site mentioned in my previous e-mail. And I 
>>> was not able to reproduce your crash neither by scrolling the Media 
>>> Sizes in Page Setup Dialog, nor by moving in that list using the 
>>> keyboard.
>>>
>>> Did you get this crash with the latest source code of the whole JDK 
>>> 8 patched with the fix? Do you use the test application provided on 
>>> the bug's record page? Perhaps, you are using a "fastdebug" build of 
>>> JDK 8, if it is so, then can this kind of build be considered as a 
>>> reliable for verification of fixes?
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 4/19/2013 1:21 AM, Jennifer Godinez wrote:
>>>> Hi Anton,
>>>>
>>>> I got a crash when I tried to go down the list of Media Size in 
>>>> Page Setup Dialog.  Output is below.  Can you confirm?
>>>>
>>>> Jennifer
>>>>
>>>> OUTPUT:
>>>> ---------------------------
>>>> PrintService = Win32 Printer : PrimoPDF
>>>> *********************
>>>> AWT Assertion Failure
>>>> *********************
>>>> value != NULL
>>>> File 'Hashtable.cpp', at line 124
>>>> GetLastError() is 0 : The operation completed successfully.
>>>>
>>>> Do you want to break into the debugger?
>>>> *********************
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> #  Internal Error (os_windows_x86.cpp:143), pid=8932, tid=9484
>>>> #  guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: 
>>>> Unexpected result f
>>>> rom topLevelExceptionFilter
>>>> #
>>>>
>>>>
>>>> On 4/17/2013 9:49 AM, Jennifer Godinez wrote:
>>>>> Thanks Anton.  I will test your fix and let you know.
>>>>>
>>>>> Jennifer
>>>>>
>>>>> On 4/17/2013 5:53 AM, Anton Litvinov wrote:
>>>>>> Hello Jennifer,
>>>>>>
>>>>>> Thank you very much for the review of this fix. For reproduction 
>>>>>> of this bug and testing of the fix the printer "PrimoPDF" with 
>>>>>> its driver "PrimoPDF" was used. This printer is a virtual printer 
>>>>>> which generates PDF files as a result of printing jobs and which 
>>>>>> can be downloaded at the URL (http://www.primopdf.com). Such a 
>>>>>> printer was selected for testing, because it supports the paper 
>>>>>> size "11 x 17" in inches, with which the bug was experienced by a 
>>>>>> user according to the bug report.
>>>>>>
>>>>>> Also I was able to observe a similar situation with the printers: 
>>>>>> "Microsoft XPS Document Writer", "Xerox WorkCentre 4250 GPD PS" 
>>>>>> but on paper sizes different from "11 x 17". For example, if the 
>>>>>> printer "Xerox WorkCentre 4250 GPD PS" is used, JDK interprets 
>>>>>> the paper size "Postcard (100 x 148 mm)" as "Postcard (JIS)" and, 
>>>>>> when algorithm of the method 
>>>>>> "sun.print.Win32PrintService.getMediaSizes" encounters the paper 
>>>>>> size "Japanese Postcard", it interprets it as "Postcard (JIS)" 
>>>>>> again, which leaves just one media size "Postcard (JIS)" from 2 
>>>>>> in Java cross-platform Page Setup and Print dialogs. I think that 
>>>>>> this situation is similar to the case with "11 x 17" paper size, 
>>>>>> because some user can also be willing to see exactly "Postcard 
>>>>>> (100 x 148 mm)" media size in the mentioned Java dialogs, where 
>>>>>> it will be absent, whoever this fix still will not allow 
>>>>>> "Postcard (100 x 148 mm)" to be displayed.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
>>>>>>> Hi Anton,
>>>>>>>
>>>>>>> What printer and printer driver version did you use to test your 
>>>>>>> fix?
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Jennifer
>>>>>>>
>>>>>>> On 3/11/2013 1:41 AM, Anton Litvinov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the following fix. This is the second reminder 
>>>>>>>> message. Please take into account that the original review 
>>>>>>>> request was sent more than 1 month ago and no response has been 
>>>>>>>> received yet.
>>>>>>>>
>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>>
>>>>>>>> On 2/21/2013 6:53 PM, Anton Litvinov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I am sorry for inconvenience. This is a reminder message. I am 
>>>>>>>>> still interested in reception of the response to this review 
>>>>>>>>> request and just want to be sure that it is not lost on the 
>>>>>>>>> mail alias's archive.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>>> On 2/8/2013 8:09 PM, Anton Litvinov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>>
>>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>>>>>
>>>>>>>>>> The bug consists in the fact that Java cross-platform Page 
>>>>>>>>>> Setup and Print dialogs do not always list all media sizes 
>>>>>>>>>> supported by a printer. The fix is based on addition of 
>>>>>>>>>> dynamic creation of new media names of the type 
>>>>>>>>>> "sun.print.Win32MediaSize" based on paper names received from 
>>>>>>>>>> Windows API function with corresponding media sizes of the 
>>>>>>>>>> type "javax.print.attribute.standard.MediaSize" for the case, 
>>>>>>>>>> when the printer's media size name, which is being analyzed 
>>>>>>>>>> in "sun.print.Win32PrintService.initMedia" method, is not 
>>>>>>>>>> added to the final list of media sizes supported by the 
>>>>>>>>>> printer because of an already existing duplicate in that 
>>>>>>>>>> list. In such a case the printer's paper size matches with 
>>>>>>>>>> one of the media sizes registered in JDK, while the paper 
>>>>>>>>>> size ID does not match with any ID known to JDK.
>>>>>>>>>>
>>>>>>>>>> Also the code in "Win32PrintService.findWin32Media" method 
>>>>>>>>>> was altered to allow three cases from "switch" block to work 
>>>>>>>>>> as expected, because currently they never match with 
>>>>>>>>>> "dmIndex" value, since it is always less then 
>>>>>>>>>> "dmPaperToPrintService.length" under "if" statement.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

More information about the 2d-dev mailing list