On 6/14/16, 10:09 PM, prasanta sadhukhan wrote:
Hi Phil,
On 6/15/2016 12:21 AM, Phil Race wrote:
This sound fishy. "2" does not sound like a valid value per the Microsoft spec
but this driver is apparently considering it as something like a multiplier
although
presumably not to the actual resolution.
I see that we are checking that the DM_YRESOLUTION bit of the dmFields member
is set :
1002 int xRes = devmode->dmPrintQuality;
1003 int yRes = (devmode->dmFields& DM_YRESOLUTION) ?
1004 devmode->dmYResolution : devmode->dmPrintQuality;
1005
1006 // For some printers, printer quality can specify 1200IQ
1007 // In this case, dmPrintQuality comes out 600 and
1008 // dmYResolution comes out 2 which is not a valid
resolution
1009 // so for IQ setting, we specify yresolution same as xRes
1010 if (yRes< 10) yRes = xRes;
.. so really they ought to return a DPI value as the spec says. I can't
find anything that grants the apparent latitude being taken here.
Note that your change here looks like it may break "quality" - where
the pre-defined values are negative - as you will overwrite "-1" (for
example) with 10.
Actual breakage depends on whether we bother to read yRes in the case
that
xRes is negative but it still should not be over-written.
If "quality" or dmPrintQuality is pre-defined negative value
(like**DMRES_HIGH, DMRES_MEDIUM, DMRES_LOW, DMRES_DRAFT)
then it will be handled in the "if" block
and my modification is in "else" .
Not following that but in any case ...
At a minimum you need to fix the code to look like :-
int yRes = (devmode->dmFields& DM_YRESOLUTION)&& (devmode->dmYResolution< 10)
? devmode->dmYResolution : devmode->dmPrintQuality;
I guess you mean
devmode->dmYResolution> 10
.. yes
Anyways, I have updated webrev to accomodate your comment.
http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.01/
approved since we have a comment explaining the "logic" but still puzzled.
-phil.
But I find it a little unsatisfactory to have to make this kind of workaround
and wonder what we are missing ...
I could not find anything but this will help in getting printing to be
working in those printers. If we find anything in near future, we will
update this code .
Regards
Prasanta
-phil.
On 06/09/2016 04:35 AM, prasanta sadhukhan wrote:
Hi All,
Bug: https://bugs.openjdk.java.net/browse/JDK-6966350
The issue was if we select 1200IQ Normal (default) setting in
Lexmark E352dn PS3 or Dell 5310n printer, it does not print the
output and we get empty pages.
It was because DEVMODE windows structure returns 600 for
"dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns
600 dmPrintQuality and 4 as dmYResolution
so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls
WPrinterJob#setResolutionDPI(xres=600, yres=2) and
RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres
= 2)
so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0,
-108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets
devPos x= 725.33, *y = -105.22**.
*so nothing gets printed.
I tried finding the significance of 1200IQ setting which just says
it enhances the images sent to the printer.
From
http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm
(although it's not the same printer)
says /"//To be fair, the LaserJet offers sharper resolution — 1,200
by 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what
Lexmark calls "1,200 Image Quality" dot placement for photos"
/I modified the code to set yres to xres value if yres is less than
10 . Although it seems to be a workaround, it prints the output.
webrev: http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/
Regards
Prasanta
