I am ok with this fix.
-phil.
On 4/23/2013 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
