I have a very weird JasperReports rendering problem.
I am using an old version of the free Java Reporting Tool JasperReports: 1.3.4. It's being heavily used on a Swing finance application.
I use JasperViever class to show a preview of the report to print, and my weird problem is that the report shows perfectly fine on some computers while it erases some end-paragraph-lines in others. Paragraph is laid out on the title section and it's four or five lines length. It's being rendered from a string field value.
All computers run the exact same version of the application, compiled report, operating system (Windows XP) and Java Virtual Machine (1.6.0).
What is JasperReports' JasperViewer class using to render the report that is causing different outcomes with different computers? Different installed fonts on Windows? Different Video Cards?
One more thing to it: if I export the report to a PDF or HTML, the problem disappears. The resulted file I generate on every computer shows every single line of the paragraph. So I know the info is there. It's just not being rendered on some computers when I user JasperViewer class. When I print it, I get exactly what JasperViewer class shows on preview.
My reports are displaying loan contracts to print them and hand them to customers. So it's extremely important to have them complete! :-)
Related
I am currently working on a project for my first java team project. I have run into an issue where a certain class will suddenly stop showing errors (when I try to build my project, the output will show an error as shown in the screen capture, but I won't see an error in the text editor). I wrote a bunch of nonsense at the last line for you to see what I mean. Also, my attributes normally show in purple text and they now show in white text which is normally the indicator that the class in question won't show errors. This only affects some classes, most of them I worked on recently and have not been committed and pushed to my gitlab repo.
This makes coding a pain since I never know if I have made a stupid mistake until I try to build the project. I have not fiddled with the IDE, the only thing I did was change the font to the Jetbrains one and put on the default Netbeans dark theme.
Any help would be appreciated.
Try to delete Netbeans Cache folder (after closing Netbeans of course). On Windows systems it is usually located under C:\Users\<<username>>\AppData\Local\NetBeans\.
While typing my code out, some lines automatically get spaced out, and whenever I try to click or type something, more lines disappear in the process, therefore making me delete the class itself.
I have encountered this same issue on another system.
I cannot even Ctrl+A my code, help!
Screenshot:
The BlueJ FAQ mentions possible display artifacts on Windows:
There are visual artifacts on the BlueJ windows (black areas,
distorted text, etc) in Windows
Visual artifacts - black areas,
distorted or missing text, etc - are usually a result of either a
display driver bug or a Java bug. Try updating your display drivers
(see here for Windows 7) or disabling graphics acceleration (see
here).
https://bluej.org/faq.html#win_visual_artifcats
It makes several recommendations for how to fix them:
update display drivers
update JDK
change VM args
Read the linked FAQ for instructions.
The release log also tells a similar story, so make sure you've updated BlueJ:
4.1.0 23 June 2017
Major fixes:
Fixed: Graphical display bug could cause the Java editor and other
windows (e.g. Terminal) to turn white and not redraw correctly.
https://bluej.org/versions.html
I wrote a java program, which manipulates Word documents (docx) with Apache POI. It runs fine within Eclipse, and it runs fine as a runnable JAR on my computer (Windows 10).
I copied that JAR to another computer, and it is starting up normally. The GUI behaves like expected.
The problem is the Word document I write out (docx).
I am performing two types of changes. The first one is the addition of new paragraphs or concatenation of content to the runs. If I stay with this, the document gets written into the file system correctly. The second type is the simple replacement of content within the runs (changes of words and some grammatical changes). I would see that part as the "simpler" one, but if I stay with this or if I combine both change types, no document is written out at all. It does look like there is a bug, but there isn't one because it worked fine on my system.
I wrote myself a function to write out an error log (txt) to get information about that issue. This one worked on both systems. But the log didn't get any information, why the document was not written out.
I suppose there are some Windows security settings which interfer with my program or something like that. The computer that does not like to run my program has Win 7 installed on it, and there are some security domain settings, which affect all other computers in the local network.
Does anyone experienced something similar yet? Any suggestions what to check? Suggestions how to find out if an error happened are appreciated as well.
OK, the problem got solved by simply updating the Java version. I saw that update icon in the system tray, which didn't open update the update dialog. So I wanted to update the Java-version at least.
When I wanted to de-install the current Java version first, I noticed that the Win7-machine hadn't a Java-update for three years now. It was just installed in 2014. As soon as the recent version was installed, everything worked like expected again.
The strange behavior that some parts of my program worked and some not, confused me. I hoped that the Java update would fix this, but I doubted that. I didn't knew that old versions make programs run unpredictably.
Now I am using a plugin based Java to put into a third party software (ImageJ) to process images. After inputting images, it shows the GUI where I can choose the segmentation parameters and tracking parameters. But it runs slowly after setting parameters on the GUI. Hence, I want to know which part(Segmentation or Tracking) makes the Java code run slowly.If I use Eclipse, can I get the running time of each part and how I can get it because it's a plugin and the running time will be different if I change the parameters on the GUI and input images. Thank you so much.
Okay, so here's my problem:
We use FOP for creating "pretty" report output. We use the pdf option if the user wants a file, AWT for previewing, and the -print option for printing them. We are using FOP 0.25.x, which I fully recognize is not the newest version, but upgrading to 0.95 appears to be a non-trivial task that I don't necessarily want to undertake.
Anyway, it was noticed by one of our users that when printing ID cards (generated via FOP -print option) to the id card printer, the images on the cards (pictures of the employees) had some corruption in them...sort of like like green and reds dots and lines. We also discovered that if we sent the exact same print request to one of our HP color laserjets, it printed fine. To add to the strangeness, if we use FOP to create a PDF of the ID card and then print it via acrobat reader on the card printer, it prints fine.
I eventually discovered that it had something to do with the scaling of the images...we were scaling 600px high images down to something like 120px. If I presized the images down, even just halfing them, the corruption went down noticeably. Similarly, when I upsized the images, the corruption went up.
So my question: anybody have ANY idea what is going on here? Or has ever run into such a thing?
Since I don't know why this is happening, I don't know how to fix the root cause, but I've been working through some various workarounds:
1) Use FOP to create a pdf of the image and then print that via Java. This seems like an obvious answer, but some Googling around showed that printing a PDF via Java is not trivial. I've seen the PDF Renderer project on java.net, but seems pretty bulky for a single very specific application.
2) Try to resize the images before giving it to FOP. This also seemed pretty straightforward, however our various users can setup stylesheets for these id cards however they want and using "pt" and "in" sizing in them seems to be pretty common...I don't know of any good way to map that to a pixel resizing.
If anybody has any insight into the root cause, ways to make these work arounds work, and/or another idea, you'd be in my debt.
Most certain explanation:
image corruption? it's a bug.
Why not use 0.95? Sooner or later you have to upgrade, Apache consortium won't
fix bugs in 0.25.x versions.
You can't hope to find workarounds for every bugs which might occur in future.
I ended up doing the second thing I mention in the original question...i.e. resizing it before giving it to FOP. I found that I could retrieve the dpi of the printer I was printing to and do some math on it to get pixel sizing. Seems to work perfectly in all my testing...not a real solution but an adequate workaround.