The result of printing was ugly with drawString after 
setColor( new Color(0,0,0,200)).

1. Configration
  1.1 OS       : Windows95(OSR2), IE4.01
  1.2 JDK ver. : Kestrel build-P
  1.3 Printer
     (1) Fuji  customer  Laser Press 4150 PSII(Postscript printer)
         (Driver: win85/98 Postscript driver( customer  PS Ver. 4.2.6))
     (2)  customer  Laser shot LBP 730 (Page printer)    
         (Driver:  customer  Lips4 Win95/98 driver ver. 6.3)

2. Reproduction

 Please use the attached file, PrintImage.jar
 
 1.1 Process
   
   1) Set your printer "Default printer"
   
   2) Execute "java -jar PrintImage.jar"
      -> Canvas will appear, and display "PrintSample!"
         
   3) In menu, Select "File" - "PrintTest1"
      -> Print Dialog will appear
      
   4) Click "OK"
      -> Printing Job will start
      
   5) In menu, Select "File" - "PrintTest2"
      -> Print setup Dialog will appear
      
   6) Click "OK"
      -> Print Dialog will appear
           
   7) Click "OK"
      -> Printing Job will start
      
     
   As to the results of printing, "Printtest1" was ugly, and 
   "Printtest2" was  customer . 
    
3. Source code
  Please see the attached files , PrintImage.java and PrintImageCanvas.java.




java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)

In jdk 1.3 the workaround with set property
sun.java2d.print.pipeline=pdl only works for colors without
a alpha component. For colors with a alpha component the bug
also occured, if the property sun.java2d.print.pipeline=pdl
is set. Without setting the property the bug occurs on every
printing using colours. If you print only in grey-scales there
is no problem. I found no effect with the PaperFormat (I have a german WIN-NT System with DIN-A4 as default Page-Size).

The bug occured on every Printer I have tested:
HP LaserJet 4050 T PCL 6
HP LaserHet 4000 Series PCL 6
HP DesignJet455CA(E/A0)
QMS magicolor 2 DeskLaser
(Review ID: 116432)
======================================================================

Set the property sun.java2d.print.pipeline=pdl

The only problematic consequence of this is that Alpha components of colours may be ignored.

The test in question uses a colour with an alpha component, so the
raster printing path is invoked.
We use a 3 byte BGR DIB and send this to the printer.
There appears to be a problem with the scanline stride on some printers.
So far several Japanese page printers are the only ones which show the problem.
Numerous other printers do not. I am inclined to suspect a printer driver bug.

========================================

Image passed to SetDIBitsToDevice is not DWORD aligned because width image of buffered image is not a multiple of 4.  

  xxxxx@xxxxx   2001-02-15
=========================================

I have the same printing problem.
The printing is done in bands of about 10 mm height, eaach 
band is slanted 45 degrees to the left and colors are 
wrong. It also happens on b/w printers, color laser and 
inkjet.  (Brother, Colorbus, HP)

I think it might not be in the printerdriver. On the 
Brother printer (I don't have access to the others at the 
moment) printing goes wrong when I choose A4 as 
paperformat. But with Letter, the printing is correct!
Could it be that internally the wrong numbers are used to 
create the bitmap??

Another note:
If I get the PaperFormat (defaultPage()) and set the 
imageable area so that the left&right margin are 58.0, 
printing is ok on letter & A4.

Another workaround (again leading me to think this is NOT a 
driver bug): the JRE 1.3 from IBM prints OK with Alpha 
channel (and I'm sure it also rasters the complete page, 
looking at the size of the printjob).

In jdk 1.3 the workaround with set property 
sun.java2d.print.pipeline=pdl only works for colors without 
a alpha component. If one color with a alpha component is 
used the bug occured. In 1.3 I found no effect with the 
PaperFormat.

We also run into this printing problem using jdk1.3.1 and found 
that the ugly printing would occur if any of the following is 
true:
1. alpha component in Color is set to any value in the range 
of 0-254 (i.e some level transparency is set)
2. use of AlphaComposite
3. use of XOR mode

In our application, we only use full transparency (i.e. alpha = 
0). So as a workaround for (1), instead of telling the graphic 
to paint the component with transparent background we just 
not paint the background at all.  We couldn't find any 
workaround for (2) and (3), so decided to remove them from 
our app for now (which greatly limit our app).

We tested this problem on several computers, all have the 
same driver installed.  Before the workaround as mentioned 
above, we were able to reproduce it consistently on ONLY 
some computers, not all, which lead me to think this may not 
be a printer driver issue.  Could Sun please re-investigate this 
bug!!!