JDK-6337338 : Printing of medium sized text files causes a very large spool file.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-10-14
  • Updated: 2010-04-02
  • Resolved: 2005-11-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u7Fixed 6 b62Fixed
Description
FULL PRODUCT VERSION :
JRE 1.5.0_05-b05

ADDITIONAL OS VERSION INFORMATION :
Windows XP SP1

A DESCRIPTION OF THE PROBLEM :
Our customers have problems printing big HTML or text files from our application using java.awt.print.* classes. The same bug occurs in JEdit, so I use JEdit to describe the problem:

When I print a 580 KB text file with JEdit and JRE 1.4.2_06 I get a spool file with 1,69 MB. When I print the same file with JRE 1.5.0_05 the spool file has 196 MB (100 times bigger than the file created by 1.4.2).
The problem occurs with CSV files or with text files containing 'complex' contents (e.g. program code).
It does not occur when I print a file that consists of simple lines like "yet another test line" repeated many times. I.e. if I print a file that is 500 KB big but only contains many of these simple lines the problem does NOT occur.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just create a approx. 500 KB big file consisting of the lines pasted below. Open the file in JEdit and print it. Set the print queue offline and watch the size of the spool file.
1.4.2_06 - 181 pages - size of spool file: 1,69 MB
1.5.0_05 - 181 pages - size of spool file 196 MB

Part of example file:

Name; ;Soll; ; ; ;S;e;p;t;e;m;b;e;r; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;Diff
  Vorname; ;GLZ; ; ;

;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;28;29;30;1;GLZ
  Pers.-Nr.; ;URL; ; ;

;Do;Fr;Sa;So;Mo;Di;Mi;Do;Fr;Sa;So;Mo;Di;Mi;Do;Fr;Sa;So;Mo;Di;Mi;Do;Fr;Sa;So;Mo;Di;Mi;Do;Fr;Sa;URL
Smith

C.;;344:00;hl;HL;--;--;--;--;--;hl;.,;--;--;--;--;--;.,;--;--;--;--;--;--;HL;hl;--;--;--;--;--;hl;HL;--;--;--;--;-22

4:00
Smith

M.;;344:00;NK;hl;.,;hl;.,;--;--;.,;hl;NK;hl;NK;--;--;NK;hl;NK;hl;.,;--;--;U;U;U;U;U;--;--;U;hl;Kh;K;K;--;-8:00
Smith

I.;;129:00;U;U;U;--;--;--;--;U;U;U;--;--;--;--;U;U;U;--;--;--;--;?;?;?;--;--;--;--;?;?;?;--;--;--;-9:00
Smith

M.;;344:00;.,;hl;.,;HL;hl;--;--;.,;hl;.,;hl;HL;--;--;.,;.,;hl;hl;HL;--;--;.,;HL;hl;.,;U;--;--;hl;.,;HL;.,;hl;--;-8:0

0
Smith

D.;;275:12;HL;hl;hl;.,;hl;--;--;HL;.,;hl;.,;--;--;--;.,;U;U;U;--;--;--;--;U;U;U;--;--;--;HL;hl;.,;.,;--;--;-11:12
Smith

E.;;344:00;U;U;U;U;U;--;--;.,;hl;HL;.,;hl;--;--;.,;HL;hl;.,;hl;--;--;hl;hl;.,;HL;hl;--;--;.,;hl;hl;hl;U;--;-8:00
Smith

C.;;344:00;.,;.,;HL;hl;hl;--;--;.,;HL;.,;NK;hl;--;--;NK;NK;NK;HL;hl;--;--;.,;NK;HL;hl;hl;--;--;.,;NK;.,;hl;HL;--;-8:

00
Smith

K.;;344:00;hl;.,;hl;hl;HL;--;--;hl;.,;hl;HL;.,;--;--;.,;hl;HL;hl;.,;--;--;hl;.,;hl;hl;HL;--;--;.,;.,;hl;HL;hl;--;-8:

00
Smith B.;;344:00;U;U;U;U;U;--;--;U;U;U;U;U;--;--;U;.,;.,;s/;.,;--;--;.,;.,;.,;.,;.,;--;--;.,;.,;U;U;U;--;-8:00
Smith

F.;;344:00;.,;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;--;NK;NK;NK;NK;NK;--;-8:

00
Smith

A.;;344:00;.,;.,;U;U;s/;--;--;.,;.,;.,;.,;.,;--;--;HL;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;--;vu;~;.,;.,;.,;--;-7:00
Smith

H.;;344:00;.,;.,;.,;.,;.,;--;--;.,;.,;.,;K;.,;--;--;hl;.,;.,;Su;U;--;--;.,;.,;U;.,;.,;--;--;.,;.,;U;U;U;--;-8:00
Smith

B.;;344:00;.,;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;--;U;U;U;U;U;--;--;.,;.,;s/;.,;.,;--;--;.,;.,;.,;.,;.,;--;-8:00
Smith C.;;103:12;U;U;U;U;U;--;--;?;?;bh;?;?;--;--;?;?;bh;bh;bh;--;--;?;bh;?;?;bh;--;--;?;bh;bh;?;bh;--;-24:00
Smith

J.;;344:00;U;U;U;U;U;--;--;U;U;U;U;NK;--;--;NK;NK;NK;U;U;--;--;U;U;U;U;U;--;--;U;U;U;U;U;--;-8:00
Smith

T.;;344:00;.,;U;U;.,;.,;--;--;vu;U;.,;.,;.,;--;--;U;U;U;U;U;--;--;U;U;U;.,;.,;--;--;.,;.,;.,;.,;.,;--;-8:00
Smith

M.;;344:00;U;U;U;U;U;--;--;.,;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;--;.,;.,;.,;.,;.,;--;-8:00
duty1;;;;;;4;4;;;3;4;3;3;3;;;2;3;3;4;3;;;3;3;3;3;3;;;3;4;3;3;3;;-371:12
duty1;;;;;;;1;;;;;;;;;;;;;1;;;;;;1;;;;;;;;;;;
duty1;;;;;;;;;;1;;;;;;;;;;;;;;;;;;;;;1;;;;;;
duty1

Term;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;1;;;;;
duty1;;;;;;;;;;;;;1;;;;;;;;;;;;;;;;;;;;1;1;1;;
duty1

verplant;;;;;;5;6;;;;6;5;5;5;;;;7;5;5;4;;;;6;6;6;5;;;;6;5;4;3;;
duty1;;;;;;6;5;;;3;4;3;2;1;;;4;4;4;4;4;;;3;4;5;3;3;;;2;1;3;3;4;;
duty1.

Abwesend;;;;;;;;;;;;;;;;;;;;1;;;;;;;;;;;;;;;;;


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The 1.5.0 spool file should be as small as the 1.4.2 spool file.
ACTUAL -
see above

REPRODUCIBILITY :
This bug can be reproduced always.
Comments
EVALUATION There is also another issue - the user test case prints a Swing component and Swing now (1.5) prints using TextLayout [This is the real reason that TextLayout was used and "the missing override" isn't in fact missing] with a screen font render context in for reasons of correctness. This means each glyph is "adjusted" to its screen position and so a lot depends on how compactly the printer driver can represent this in the spool file. So whilst the above suggested fixes will help most cases, it won't help Swing "screen dumps" as much. Long term the best solution there for dumping the contents of large swing text components is to adopt the new JDK 6 APIS on JTextComponent for direct printing. What may help is if we can use the GDI API which lets you specify the advances of glyphs to drawString. That is may be more compact but still not as compact as using default advances since extra information takes space! Need to file a new bug to address this part of it.
15-10-2005
EVALUATION The text is mostly printing as filled outlines. The initial cause of the problem is a missing override in WPathGraphics which results in a delegation that goes via TextLayout and drawString is ultimately used by recreating the text from a glyphvector. It looks like an oversight that didn't generally cause problems because the result should be the same, although perhaps more computationally intensive than it needs to be. But some characters make the text prints as shapes. Eg it turns the 0x3e (;) into 0x37e - a greek character. The code which tests if the GDI font can handle this fails. The problem is that the code that sets up a reverse cmap (glyph->char) will use the highest code point mapping of the glyph. It can't (currently) handle multiple mappings and probably ought to be using the lowest codepoint. That's another easy fix. So that's the root of the 1.5 issues. A 1.6 specific issue is that we are printing as individual glyphs. This is introduced in mustang when fixing 6186840: GlyphVector.setGlyphPosition has no effect when printing This was a problem where an app was explicitly setting glyph positions and we overlooked that. But the fix was overly stringent as layout is unfortunately always setting that flag : ie StandardGlyphVector.createGlyphVector has : // !!! layout engines need to tell us whether they performed // position adjustments. currently they don't tell us, so // we must assume they did _flags |= GlyphVector.FLAG_HAS_POSITION_ADJUSTMENTS; This was already noted in the printing code and PathGraphics.java has /* The same codes must be in the same positions for this to return true. * This would look cleaner if it took the original GV as a parameter but * we already have the codes and will need to get the positions array * too in most cases anyway. So its cheaper to pass them in. * This call wouldn't be necessary if layout didn't always set the * FLAG_HAS_POSITION_ADJUSTMENTS even if the default advances are used * and there was no re-ordering (this should be fixed some day). */ private boolean samePositions(GlyphVector gv, int[] gvcodes, int[] origCodes, float[] origPositions) { and in other places we apply that test too before concluding there really are position adjustments. So we need to apply that logic here too.
14-10-2005