JFreeChart print job size.
JFreeChart print job size.
I have noticed that when printing a Chart from the JFreeChart web start demo, that the print job shown in my print queue shows a size of 96.3mb. This seems to happen regardless of the Chart type, and is nearly always 96.3 mb.
To further investigate, I tried printing a Chart to a PDF writer (in my case Cute PDF), still, the print job shows a size of 96.3mb, but the resulting file is drastically less (200kb).
Has anyone noticed this problem. I mean, what determines the print job size? Surely it shouldn't be 96.3mb.
This seems to me to be a bug, any takers?
To further investigate, I tried printing a Chart to a PDF writer (in my case Cute PDF), still, the print job shows a size of 96.3mb, but the resulting file is drastically less (200kb).
Has anyone noticed this problem. I mean, what determines the print job size? Surely it shouldn't be 96.3mb.
This seems to me to be a bug, any takers?
-
- JFreeChart Project Leader
- Posts: 11734
- Joined: Fri Mar 14, 2003 10:29 am
- antibot: No, of course not.
- Contact:
It's a while since I looked at the printing code, but in the past the most common problem has been *some* printer drivers seeing things like GradientPaint and anti-aliasing and only supporting these by creating bitmaps which can be very large at printer resolutions. I don't know any good solutions for that. But if you find any workaround, or the problem turns out to be something else, please post back here.
David Gilbert
JFreeChart Project Leader
Read my blog
Support JFree via the Github sponsorship program
JFreeChart Project Leader


-
- Posts: 9
- Joined: Thu May 08, 2008 3:18 pm
Here's print job sizes that I've noticed when printing identical LineChart to few printers:
HP LaserJet 1320 (laser) - 640KB
Xerox Phaser 1235 (laser) - 15,9MB
Epson AL-C1900 (laser) - 4,25MB
Canon iP5300 (ink) - 63,7MB
PDFCreator - 60,7MB
Environment:
WindowsXP Professional SP3
jre 1.6.0_06
jfreechart 1.0.10
jcommon-1.0.13
HP LaserJet 1320 (laser) - 640KB
Xerox Phaser 1235 (laser) - 15,9MB
Epson AL-C1900 (laser) - 4,25MB
Canon iP5300 (ink) - 63,7MB
PDFCreator - 60,7MB
Environment:
WindowsXP Professional SP3
jre 1.6.0_06
jfreechart 1.0.10
jcommon-1.0.13
-
- JFreeChart Project Leader
- Posts: 11734
- Joined: Fri Mar 14, 2003 10:29 am
- antibot: No, of course not.
- Contact:
Thanks for the numbers. Do they vary if the chart has antialiasing or not? And gradients?
David Gilbert
JFreeChart Project Leader
Read my blog
Support JFree via the Github sponsorship program
JFreeChart Project Leader


The spool-file size is dependent on many factors:
(1) Your printer: Bitmap printer (Ink-Jet) or Vector printer (Laser printer; PCL and Postscript)
(2) Your printer driver
(3) Your JDK
When printing in Java, the JDK tries to map all Graphics2D operations directly into native rendering operations (vector-to-vector mapping). If that fails because your printed content contains non-vector stuff (like transparencies, images, gradients), then the JDK switches into a bitmap mode, where the whole content is rendered to a image and then the bitmap is printed. Usually, this bitmapped mode is what's causing the large spool files.
The JDK communicates with the printer driver, which in itself can choose to switch from vector to bitmap mode if it feels the need for it. Depending on how efficient the driver is, you may end up in a large whole-area bitmap or a mix up of vector and bitmap areas. Needless to say that with printer prices down to 150$ your chances of having a sane driver are down as well.
Depending on the JDK you use, you may see improvements in the printing - JDK 1.4 and 1.5 are nice, but suck big time compared to JDK 1.6.
(1) Your printer: Bitmap printer (Ink-Jet) or Vector printer (Laser printer; PCL and Postscript)
(2) Your printer driver
(3) Your JDK
When printing in Java, the JDK tries to map all Graphics2D operations directly into native rendering operations (vector-to-vector mapping). If that fails because your printed content contains non-vector stuff (like transparencies, images, gradients), then the JDK switches into a bitmap mode, where the whole content is rendered to a image and then the bitmap is printed. Usually, this bitmapped mode is what's causing the large spool files.
The JDK communicates with the printer driver, which in itself can choose to switch from vector to bitmap mode if it feels the need for it. Depending on how efficient the driver is, you may end up in a large whole-area bitmap or a mix up of vector and bitmap areas. Needless to say that with printer prices down to 150$ your chances of having a sane driver are down as well.
Depending on the JDK you use, you may see improvements in the printing - JDK 1.4 and 1.5 are nice, but suck big time compared to JDK 1.6.