(glyph->char) will use the highest code point mapping of the glyph. The problem is that the code that sets up a reverse cmap The code which tests if the GDI font can handle this fails. More computationally intensive than it needs to be.īut some characters make the text prints as shapes.Įg it turns the 0x3e ( ) into 0x37e - a greek character. It looks likeĪn oversight that didn't generally cause problemsīecause the result should be the same, although perhaps Via TextLayout and drawString is ultimately used by WPathGraphics which results in a delegation that goes The initial cause of the problem is a missing override in The text is mostly printing as filled outlines. The 1.5.0 spool file should be as small as the 1.4.2 spool file. 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 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Ĭ.
#Jedit diff Offline
Set the print queue offline and watch the size of the spool file.ġ.4.2_06 - 181 pages - size of spool file: 1,69 MBġ.5.0_05 - 181 pages - size of spool file 196 MB 500 KB big file consisting of the lines pasted below. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : if I print a file that is 500 KB big but only contains many of these simple lines the problem does NOT occur. It does not occur when I print a file that consists of simple lines like "yet another test line" repeated many times. The problem occurs with CSV files or with text files containing 'complex' contents (e.g. 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). 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. The same bug occurs in JEdit, so I use JEdit to describe the problem: Our customers have problems printing big HTML or text files from our application using .* classes.
0 kommentar(er)
