> Since (surprise) 'pdl' didn't help try 'raster', which is the opposite > of what you think is helpful but might be interesting.
Thanks for the answer but I think the sarcasm is misplaced. Pease google "sun.java2d.print.pipeline" and see for yourself how much information you get. I could not find a list the possible values nor an explanation of what they do, only a hint that pdl might be a good idea. >> Furthermore it seems this decision reflects late 1990s thinking re. the >> capabilities and speed of some printers. Isn't it time to revisit? > > No, its the late eighties Microsoft APIs that limit what we can do. How do the MS APIs come into the picture? Unless we are talking about so-called Windows printers that render on the desktop and thus using GDI, I would not think they are involved. To be sure they are an important use case but they are not even the majority of printers. In any case the point is not just printers: you can "print" or "paint" to Graphics2D instances that generate PostScript, PDF, SVG or whatever and it is extremely unhelpful when they are sent a bitmap instead of the expected graphics instructions that you put in your code. There ought to be a switch to turn off rasterization *unconditionally* and ensure graphics command are sent exactly as they are written. As it is, the only way I could find to do that is to bypass the high-level print/paint methods and call paintCompoment and paintBorder directly. That works but then I have to perform nested widget placment, background printing etc manually, which is quite a bother. Is there a better way that I have overlooked? Regards, -- O.L. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
