Hi,
V. large spool files is a problem we've been tackling by reducing
the cases where the circumsances that cause them are necessary.
They are encountered only (so far as I know) when using a Postscript or
perhaps PCL printer. Raster printers don't have this problem.
Here's about every gory detail I can think of on this subject,so
you can make informed decisions.
Without more specific information its difficult to give
specific suggestions.
1) What O/S are you using? NT, or win2k, or win 9x, or Solaris ?
I have noticed that the 9x drivers generates much larger files
than NT for the same GDI calls. We've put some 9x specific
optimisations in the next major release (1.4).
2) Are you using 1.3? If not, upgrade. Its much smaller for many
cases.
3) What DPI are you using? Eg if the page is being generated as a
raster, do you really need 1200dpi? That's going to create a file
that's 16 times as big as the same output at 300dpi.
Select the lower-res option in the printer properties.
BTW printing as a raster is only used in 1.3 when compositing, or
you draw using a paint which isn't a solid color. Perhaps you can
avoid these things which trigger the problem. If you really need
to use alpha colours (for example), then doing just that
part of the rendering into an image and then drawing that image
to the printer graphics will also avoid the large spool files.
4) Here's a performance tip: when printing look at the clip.
Sometimes you can save by being smarter about not rendering outside
the clip. This tip most usefully applies to the case when the
page is printed as a raster in multiple bands.
5) Are you printing a Swing UI?
Consider that printing Swing components is often better
done by explicitly drawing it into a image and then printing that
image. This is because Swing paints its components back to front
and some rendering is simply being overwritten by newer rendering.
This doesn't matter for a raster printer, but Postscript printers
record all of that and replay it.
Apps which exhibit similar behaviours: eg if you take a terrain
map, draw it, draw other images, annotations etc on top, may also
see the problem that they are replaying all of that in PS,
rather than just the final result.
This is one case where for some pathological examples printing the
page as a raster may be better because there's so much rendering
to be replayed in Postscript.
The app's way to print as a raster is to draw into an image as
described earlier.
Here's some data points to compare your experiences:
JDK : 1.3
OS : NT 5.0 SP5
Printer: HP 5000 (Postscript) at 600dpi
Paper: 8.5 x 11 with 1in border (ie 6.5in x9in used)
Content: 1 page with approx 20 images with the entire imageable
area having a black background:
Spool file size: 400Kb.
If I "force" the same page to be printed as a raster, which
is what happens if you are using paints other than solid colours,
then the same job becomes 3.5Mb. Still more or less manageable.
However it is true that this is not the worst case scenario which is for
Postcript at 600 dpi an uncompressed page size raster of RGB colours
encoded using ASCII which may be around 80Mb. Printing that does take
several minutes, almost entirely for transmitting the spool file over
the cable to the printer. The tips above may help find a way
to improve where you encounter cases like that.
Note that the same raster sent to a cheap inkjet is about a 2Mb
spool file, although at a lower resolution (360dpi).
Also as mentioned above 1.3 is smaller for many cases. We've
tried to make the raster case get hit for fewer & fewer use
cases. Fewer developers are hitting the remaining cases.
If test cases can be provided to illustrate real problems
people are still having with their apps we can use those to focus
resources on improving those cases.
-Phil.
> X-Unix-From: [EMAIL PROTECTED] Tue Dec 12 01:27:01 2000
> X-Originating-IP: [204.69.198.34]
> X-OriginalArrivalTime: 12 Dec 2000 09:14:02.0259 (UTC)
FILETIME=[DE48EE30:01C0641B]
> Date: Tue, 12 Dec 2000 01:14:02 -0800
> From: Yvon Sauvageau <[EMAIL PROTECTED]>
> Subject: [JAVA2D] Printing performance and spool size
> To: [EMAIL PROTECTED]
>
> Hi,
>
> I have a component that takes several minutes and 10MB of spool file to
> print. I would like to know if anyone has any optimization tips to share.
>
> I found that using a white background seems to improve the spool size
> considerably.
>
> I plan to tweak the rendering hints. I figure out that using the lowest
> quality rendering hints on a printer shouldn't deteriorate the end result
> too much because printers have very high resolutions. I guess this will
> mostly improve the time, but perhaps also the space?!
>
> Thanks for your suggestions,
> yvon
>
________________________________________________________________________________
_____
> Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
>
> ===========================================================================
> 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".
===========================================================================
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".