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".

Reply via email to