Olivier Lefevre wrote:
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.
Well since this is internal implementation of the Sun JDK, and not in fact
a standard property its not surprising its not documented.
Its principle use is internal testing.
Generating "PDL" graphics instructions ie NOT a rasterised bitmap
is what the JDK does by default and strives to do whenever it can.
So specifying PDL is either a no-op, or is possibly going to
cause a failure at runtime since you are forcing an inappropriate path.
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.
I don't know what you are driving at.
The standard way to print graphics on windows is via GDI,
unless perhaps you are a .NET app, but even then I'll bet its
translated into GDI under the covers as that's what the windows
printer driver API wants.
And GDI doesn't have an API to create a translucent color
Color c = new Color(255,255,255,128);
simply isn't available.
So things like that force a bitmap but I am doubtful its relevant
to your case :
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?
Ah! I suspect this is your application bug.
Are you seeing this only when printing a Swing UI?
How are you printing?
Are you calling "component.paint(printerGraphics) on the printer graphics.
Remember that Swing is double-buffered by default so
it does all its painting to an off screen image and that
"printerGraphics" for the printer sees only the resulting image.
So its nothing to do with the printing implementation.
You need to call Component.print() or Component.printAll() in which
case Swing renders directly to the printer graphics.
-phil.
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".
