The Dentist

Unfortunately, I can confirm the issue. I have the same problem if I have texts containing the letter ß (while umlauts don't seem to cause problems interestingly). It is important to note that the preview inside Jaspersoft Studio is fine, problem occurs only when you export the report to file. Docx and pdf are both affected, while html is not. In docx, I can see that the textfield or area or what ever is not large enough. If I make it larger, the text appears. Also, the issue seems to be related to Arial, other fonts are fine. I personally use version 5.22 of Arial, if someone could name a version that works, I'd have a workaround at least. Adding a linebreak is not an option for me as it can cause empty pages. Also, due to my enterprises policy, I can't switch from Arial. As always in cases like this, the issue is urgent for me... EDIT: I tried Jaspersoft 6.1.1 and 6.3, as library and from inside Studio.

Thank you for your quick reply. Maybe I got you wrong, but from what I see this would hardwire the location of the svg within the report. This may be a matter of taste, but I personally think that this is bad design as the server should decide on from where to load the ressources, not the report. Also, this would mean that the report developers would need access to the image via http, which is not the case. Developers are meant to develop their reports solely within Jaspersoft Studio (the server is not meant to be used at this point), where the image can be found within the report project. An URL pointing to somewhere on our server wouldn't meet the requirements, that would make report development server dependent. As of now, we have "solved" the problem by creating a subreport doing nothing else than embedding the svg (its xml source). In turn, this subreport can be included in our reports. This ways, we can have it stored in a subreport directory of our project during development and in a well-known subreport directory on the server(s) during tests and in production use. Ugly, but it suits our needs best.

As SVG seems to result in the best quality when exporting to PDF, this seems to be the way to go for our logo image. I've experimented with SVG the whole day now and found its support in the Jaspersoft Studio / Jasper Reports library quite cumbersome (although I think that it shouldn't have been treated differently than any other image format during report design). It becomes complicated especially when it's about pathing. As we'll certainly work on the reports in a team, we'll surely use some version control system to share the reports and collaborate. Now, it's definately not said that any user involved in this will have his own copy of the report project checked out to the same path. This ways, we'll certainly need to use relative paths. Even more, the filestructure on our production system (with a java server hosting our reports) might differ from what we have on our developers systems as well. Of course, I found out that SVGs can be included using the following: <image hAlign="Center" vAlign="Middle"><reportElement x="0" y="0" width="179" height="66"/><imageExpression class="net.sf.jasperreports.engine.JRRenderable"><![CDATA[net.sf.jasperreports.renderers.BatikRenderer.getInstanceFromLocation("./image/logo.svg")]]></imageExpression></image>[/code]This is said to support relative paths, which I actually don't doubt. Still, I'd say this is broken. As it is, I wasn't able to run the report from inside Jaspersoft Studio as it told me that it couldn't find the image. The image is stored in a sub-directory of my report project, the path I am using seems to be correct. When adding a variable to the report with an expression like new File($P{RESSOURCE_DIR}).getAbsolutePath() (where RESSOURCE_DIR is a parameter yielding the relative path to the directory where the image is stored and whichs value is to be overwritten by our server application later), the path turned out to be relative from my eclipses install directory (my workspace is not there and users shouldn't be forced to do so IMO). I suppose that this is what happens when calling the BatikRenderer as well. At least, passing the variable to the renderer did not seem to be a problem, only the path is not resolved properly. Does anybody have an idea how to specify a relative path using a placeholder parameter that can be overwritten by my server application?

Alright, I think everything is clear now. Of course, you were right with your assumption that it's not an exception that is thrown here, but an error. I'd say that it is not the business of the JasperReports library to deal with errors, so in this scenario JasperReports behaviour was fine. If I remember correctly, official sources even state that errors normally shouldn't be caught. Which is why I didn't expect my ThreadPoolExecutor to eat it. Anyways, this spcial case was my own fault. Nevertheless, the whole thing led me to the solution for the initial scenario causing this behaviour in my server application: if there is an image used by a report, that is unavailable during execution, a JRRuntimeException is thrown by fillReport, not a JRException. In previous versions of my application, I didn't caught any other type of exception than JRException, which led to the same behaviour as the build path misconfiguration mentioned above. This may very well be a matter of taste, but I personally don't think that fillReport should throw JRRuntimeException in this case, but an ordinary JRException. After all, if the whole report is missing, fillReport also throws a JRException and I'd say that this will likely be the case as well if subreports are missing. I don't see why missing images (styles?) should behave differently. Also, although this leads a bit far away from my initial report, I'd like to use the chance to point out a minor issue with the exporters error handling. To shutdown my server, I have to shutdown the ThreadPoolExecutor, which in turn will try to interrupt the thread that executes the report generation. In this case, exportReport of the exporter throws a JRException as usual. In this case, no special excpetion handling (logging etc.) is necessary, but to separate this from true errors, I have to check the exceptions message, which is ugly. Maybe you could throw some InterruptedException instead? EDIT: Thank you for your help ;)

My attempts to reproduce this issue were only partially successful. I was not able to set up a simple sample project as fillReport worked like you said in this case, throwing an exception when the build path is messed up intentionally with two groovy libraries of different versions (although it's not a JRException, but anyways). On the other side, I am perfectly able to reproduce the block in my server application. This ways, I suppose I am not fully innocent in this matter. I have attached the thread dump of my server application as you requested. By the following hints I'll try to make reading the dump easier to you: - My server application starts two servers: one for maintanance requests (Thread-2) and another for the actual report requests (Thread-4). - As soon as a report request is received, another thread is created to handle the communication to the client (TCPThread-0). This thread will receive a xml which it will use to parse the parameters for the report. - To generate the report, TCPThread-0 will create a runnable (ReportGenerator) that is submitted to a ThreadPoolExecutor. TCPThread-0 will then wait (using wait(...)) till the report is generated. - The report generator does all the JasperReport magic and once it is done, it sets a status on itself which the TCPThread-0 will check to see if report generation was successful. Now, the thread dump says: "pool-2-thread-1" - Thread t@32 java.lang.Thread.State: WAITING at sun.misc.Unsafe.park(Native Method) - parking to wait for <56e8c8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:662) Locked ownable synchronizers: - None This is the thread (of the ThreadPoolExecutor) that executed the generator runnable as it is mentioned in log entries of the generator before everything goes mad. Looks like the above dump is typical for cases when the thread waits for jobs from the executor. If this would be the case, then fillReport would have led to an abrupt exit of the generator runnable without letting it set it's state. In this case, the TCPThread-0 would indeed wait endlessly. Yet fillReport is placed in a try-catch that catches even Exception - so unless there is an error, really nothing should go wrong here. Also, I tried to forcefully throw a JREception which was successfully caught. I have attached the code of my generator (sorry, some text is german). I suppose the ThreadPoolExecutor is somehow involved in this problem, but I can't see how.

Changed Assigned User from @User_306070 to @anonymous @artimhamankar: As I said in my initial post, this happened to me, because there was something wrong with the 'configuration' (in a broader sense). I got that error when paths (to images, maybe subreports) were incorrect or when I messed up my classpath. I suppose that you have a similar issue with your setup. I know with this misbehaviour of the jasper report library, the reason is hard to track down (missing error handling is also a bug though), yet the block does not show up for me if everything is properly set up. So, try checking your paths and have a look at your libraries to see whether there are duplicates (maybe in different versions). I guess read / write protection could also cause this behaviour. Also, I believe it may be helpful for the devs, if you could find out what exactly does cause this to you - maybe it is a scenario easier to reproduce than mines.BTW: I downloaded and use the source project of the jasper reports library. Last time I tried their standalone library (v5.5.0, I think), I got problems of different kind (no class def found for a java EE class if I recall correctly). In the source project, you'll find all the the third party libraries as well as the jasper report library in another directory (I think it's called dist). Include them all in your build path, hope that helps.

Although having followed the instructions give here... http://community.jaspersoft.com/wiki/pdf-support-jasperreports-library ... I couldn't get PDF/A-1 to work. I tried it in the following two scenarios: 1. From Jaspersoft Studio Eclipse-plugin Using a simple Test-Report, I was trying to set up and export PDF/A in both variants according to the said instructions. The pdf files were exported and when opened, Acrobat Reader said that it is a PDF/A document, yet the pdf was empty. There is no image used by the report, yet I tried to include an sRGB icc profile (downloaded directly from the ICCs webpage), still without any luck. 2. From within a java server application using the jasper report library Using the same report, I tried to export the PDF/A using a java server application. While ordinary pdf works well, PDF/A export never really returns from the jasper report library, instead the library blocks forever. Sometimes the exported pdfs were broken and refused to open. No black magic done here, just used the code from the samples of the jasper report library (code is simplified a tiny bit to ease reading): JRPdfExporter jrPdfExporter = new JRPdfExporter(); jrPdfExporter.setParameter(JRPdfExporterParameter.PDFA_CONFORMANCE, JRPdfExporterParameter.PDFA_CONFORMANCE_1A); jrPdfExporter.setParameter( JRPdfExporterParameter.PDFA_ICC_PROFILE_PATH, Constants.RESSOURCE_DIR + Constants.ICC_PROFIL ); jrPdfExporter.setParameter(JRPdfExporterParameter.IS_TAGGED, Boolean.TRUE); [/code]and later... exporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint); exporter.setParameter( JRExporterParameter.OUTPUT_FILE_NAME, Constants.OUTPUT_DIR + filename ); try { exporter.exportReport(); System.out.println("Ready."); } catch (JRException ex) { ... } [/code] Conclusion It looks to me like this is a bug, but I am not entirely sure. Am I doing something wrong here? I have attached the report and the icc profile. BTW: My personal opinion is that setting up PDF/A using the report properties doesn't feel to be the right way as the properties are coded into the report. Yet I don't think that the report itself should deal with the output format, but instead the client app (in this case my server) should handle this. Sure, I can set and reset the properties within the server as well. Still, I think it is confusing to mess with them if the end user is, say, asking the server to export the report as Word document. Instead, there should be an exporter for PDF/A which may be derived from the default PDF-exporter.

I have to second the request for PDF/A-2. In order to comply to a specification important to our work, we would have good use for this. For us, this is really not a matter of 'because we can', but of 'because we have to'. Are there any chances to see this supported in the near future?

I can confirm this. Your two hints together solve the issue, seems like the advanced property is buggy. This bug should be reported.