aljungberg

Hey guys, It's been a couple of years but we're still trying to find a solution to this problem: Jagged 200DPI Print on Thermal Label Printer. It appears that Jasper Reports introduces shades of grey, perhaps as a side effect of bilinear image scaling, when producing its report even if the printer is strictly black and white. The thermal label printer then takes these shades of grey and convert them to a dotted diffusion pattern which ruins barcodes and other need-to-be-crisp details in black and white images. Has any controls been introduced to work around this problem? Any of the following would probably do: A property to switch image scaling method from bilinear to nearest match. A property to make a report two tone black and white. A property to prevent image scaling. The images are already the correct DPI. javax.print.attribute.standard.PrinterResolution did not work for us.Thoughts? The problem is such that even when a PDF is generated and printed from the quality of the printed report is too low (in fact this seems to make it slightly worse). The only work around we have found over the years is to download the Zebra thermal printer label drivers and set the image dithering setting to "threshold" which disables the dithering pattern and at least removes the scattered dots from the print out. Unfortunately there is no equivalent setting available in Mac OS X. Cheers, Alexander Ljungberg

I now have a report that printing in Panther is not solid either. One tester reported seeing his print degrade in quality like if the DPI sent to the printer was incorrect. This was on a fairly standard Epson Inkjet. The problems are distinct in their nature (Leopard prints have the right resolution but incorrect fonts, this Panther printer has the right fonts but incorrect resolution) but I thought I'd make a note of this here in case the print path in general has difficulties on the Mac. Has anyone heard of similar reports?

After further research I have found that the UseQuartz property does have an effect. In particular if the program is started with, -Dapple.awt.graphics.UseQuartz=true then screen rendering breaks as well as print outs. To be more specific, with UseQuartz set to true, the following code also generates reports with incorrect fonts on OS X Leopard: JRPrinterAWT.printPageToImage(...) When the settings is set to false instead as in, -Dapple.awt.graphics.UseQuartz=false then the generated images come through right but print outs still exhibit the problem. So as a simple guess, it appears that the Quartz rendering pipeline is a part of the problem and that it cannot be turned off when printing.

After further research I have found that the UseQuartz property does have an effect. In particular if the program is started with, Code:-Dapple.awt.graphics.UseQuartz=true then screen rendering breaks as well as print outs. To be more specific, with UseQuartz set to true, the following code also generates reports with incorrect fonts on OS X Leopard: Code:[code]JRPrinterAWT.printPageToImage(...) When the settings is set to false instead as in, Code:[code]-Dapple.awt.graphics.UseQuartz=false then the generated images come through right but print outs still exhibit the problem. So as a simple guess, it appears that the Quartz rendering pipeline is a part of the problem and that it cannot be turned off when printing. Post edited by: aljungberg, at: 2008/01/22 22:39

I created the following bug report for this issue: http://jasperforge.org/sf/go/artf2953?nav=1

This appears to be the same problem as described in, http://www.jasperforge.org/index.php?option=com_joomlaboard&Itemid=&func=view&catid=8&id=34025#34025

I can confirm this problem. All fonts come through with the wrong size although the positioning of each character behaves like if the size was correct. Jasper Reports version 2.0.4 Java version "1.5.0_13" OS X 10.5.1

The same problem occurs on an industrial Z4M plus printer. I am beginning to suspect that Jasper somehow generates a 300 DPI image and then tries to scale it down to the printer resolution. The scaling introduces the artifacts which is the printer's attempt at drawing grey scales created by bilinear filtering. If there was some way to tell Jasper not to scale the image up to begin with this problem would not exist. The image is exactly the right resolution from the start. Or if Jasper could be told to use black and white scaling or generate a black and white document. Anyone got any ideas?

I updated to Jasper Reports 1.3.1 but the situation did not improve.

We're using Windows XP here. The printer is a Zebra LP2844 (UPS edition), with the latest UPS drivers. I could give you the report but it's basically just a single image in an appropriately sized single band report.

Thanks for the advice. I went ahead and added a resolution attribute, PrintRequestAttributeSet prattrs = new HashPrintRequestAttributeSet(); prattrs.add(new PrinterResolution(203, 203, ResolutionSyntax.DPI)); ... printer.setParameter(JRPrintServiceExporterParameter.PRINT_REQUEST_ATTRIBUTE_SET, prattrs); This did not solve the jagged problem. What it did do was to disprove my theory that the printer itself is doing some kind of crazy scaling from 300 DPI to it native resolution and failing miserably. If I set the resolution to 75DPI I get a very small printout which none the less is just as jagged. The printer has no reason to scale a 75DPI printout. Then what's more likely is that Jasper is in fact scaling the image as it should. This is great news. But the printout is none the less jagged. Perhaps Jasper is doing some kind of bilinear scaling which results in a grayscale version of the image, which is then truncated to black and white by the printer?

We have confirmed that sending an image file with the correct DPI to Jasper works fine. If you send a 203DPI image, the printout comes through fine. But if you send a 300DPI image, Jasper seems to try to print in 300 DPI even that the printer is not capable of handling that resolution. Is there any way to convince Jasper to print with the appropriate resolution for the given printer?

I am experiencing this problem too. iReport also seems very opposed to recompiling scriptlets even when it looks like changes 'took'.

I would be glad to but apparently neither my Jasperforge login nor my Sourceforge login allow me to log in to that site. Can I post anonymously?

Nobody? I tried printing a different report printer using the thermal printer with a similar jagged result. So I'm quite sure there is something with the DPI.

I have a certain kind of report which is meant to be printed on a thermal label printer. I have created a report which is the right size, 4x6 inches, and added the single image which will be printed on the label. The PDF files generated are good but when printing straight from Jasper the report becomes distorted and gets a jagged dotted appearance. I have a hunch that Jasper is feeding the 200 DPI thermal printer a 300 DPI image (the original image file is 300 DPI), and that the thermal printer isn't doing a great job rescaling it to its own DPI. Does anyone have any experience with this? Is Jasper aware of the DPI of the printer it prints on? If a source image is a higher DPI than the printer takes, what kind of scaling, if any, does Jasper apply? If I print the PDF file generated using Acrobat Reader the result is perfect. So clearly there is some correct way to scale these images. I realize that I can just scale and send the image to the printer directly in this special case, but we need to support label printers for more general reports as well and would like to use Jasper. Anyone know anything about this?

I followed the advice in this post, http://www.jasperforge.org/index.php?option=com_joomlaboard&Itemid=&func=view&catid=8&id=9728#9728 and I am now able to use BMP images again. Perhaps in the future the automatic java.awt.Image conversion can be augmented to handle BMP when the corresponding libraries are available in the JRE. This should allow some exporters to bypass the loading process - e.g. when generating HTML or PDFs some images can be passed through or treated specially, instead of having to be loaded as potentially huge buffered images just to be re-encoded again. In my case I fear that my part of the program takes a buffered image and encodes it, stores it in a database, and then Jasper loads it from the databases and decodes it into a buffered image again just to re-encode it into a PDF specific format when the PDF exporter is used.

You were right on. For some reason BMP images worked in PDF files but not when printing. And indeed, I had the error setting set to do nothing. Curiously enough the environment I am running Jasper in does have the extended Java imaging libraries, and normally loads and writes BMP images just fine. I switched to PNG images for now. What do you think it would take to make Jasper support BMP images? I already went through some amount of trouble to write a specialized 2 color BMP encoder as a JNI extension for performance reasons. It would be a pity to have to abandon it. Come to think of it, the best way would be if I didn't have to encode the image at all. The software would run faster both on our end and on Jasper's end as we don't have to encode, and Jasper doesn't have to decode. For example, maybe we could write the data segment of a bi-planar BufferedImage straight into the BLOB and then use a cast in Jasper. Did anyone try to do something like that?

I have a dynamic image sourced from a Blob field in the database. The field has been specified as an InputSource and the image is a normal image with $F{image} as its expression. Now this works and all and the image shows up in the PDF files I generate using JRPdfExporter. The image even seems to be in its native resolution in the PDF rather than the 72 DPI resolution of JR. But when I print this very same report using JRPrintServiceExporter, the space for the image is empty! All the rest of the data is the same. An interesting perhaps related fact is that this also happens in iReport when selecting 'JRViewer preview' and creating a report. The image is missing there too. A cursory inspection of the printing code reveals that a Graphics2D object is used for rendering a raster before printing. Perhaps JRViewer uses the same Graphics2D renderer and this renderer in particular has trouble with images. Anyone know anything about this? Theories? The image is a 4x6 300 DPI black and white BMP image.