Post Edited by bdmayes at 03/23/2011 18:53
Post Edited by bdmayes at 03/23/2011 18:55
I've had exactly the same problem.
Thanks to you, I searched the report sourcefile for empty font tags, and there were quite a lot. Also, the compiler throwed exceptions with some other fonts, which actually was not in the JVM.
So, instead of setting the ignore flag, i used a texteditor and replaced these tags with fontName="Verdana", which is present at my system.
I think it's a bug in JasperReports 4.x, and not in iReport, since I actually had these empty tags in earlier versions of the same report. And they were appearently ignored and substituted with another present font.
Now, it works fine. But of course, I do not have thousands of files to edit:-)
I look forward to a new release of JasperReport where this bug is fixed:-)
Yeah I had to contact Jaspersoft support about this issue. I did exactly the same thing you did (change the empty strings to a valid font name). Unfortunately, then it complained that those fonts (Arial, Times New Roman, etc.) didn't exist. After 2 different tickets and weeks of digging we basically discovered the following:
1. The jasperreports-fonts.jar we had previously created wasn't being parsed for some reason. Jaspersoft support looked at it and claimed that it was syntactically valid and should work, but suggested that I follow a second format for the jar file as described in the JasperReports ultimate guide (specifically the "Simple Font Extension Tutorial").
2. I followed the tutorial in the ultimate guide (and had to add a few jars from the Spring framework to my classpath) and things still didn't work. I sent them the jar and they said that it was syntactically valid and should work, but must not be in my classpath (even though it was in the same WEB-INF/lib directory with all of the other jars). I went back and forth with support about whether or not my jar file was in the classpath (sending them Tomcat documention, and eventually putting Java classes in there that were found and run) before they finally accepted that my jar file was in the classpath.
3. Support finally suggested that I add the fonts in iReport and use iReport to generate the font extension jar file. This finally worked, even though it is almost syntatically identical to the original jar file we had (see item 1 above).
So I can't say why things didn't work with valid jar files, but generating the extension through iReport resolved the issue. It looks exactly the same as the one I created and packaged up manually (except instead of calling the file fonts.xml they call it fonts.xmlNNNNNNN where NNNNNNN is some random number), but for whatever reason it works and the manual jar files do not.
Once I finally got that resolved with support I just wrote some code to pull out each jrxml file from our database, parse it line by line and fix any invalid font issues, compile it, and then save the new jrxml file along with the compiled bytecode back to our database. Now I don't have any more font issues (unless someone uses a font that isn't inside the jar file -- which is their problem not mine). Ridiculous but it finally all works and we have migrated to the 4.0.0 version of JasperReports.
Post Edited by bdmayes at 05/24/2011 18:19
|Not sure what your issue was/is but possibly it is the empty string for the attribute .....|
Yes, I mention that this was definitely an issue in my original post. I'm pretty confident that my two posts above thoroughly address the issue, but there is one piece of the puzzle that was missing until recently. I mentioned before that things worked at 3.7.2 but not when I created the jar file for 4.0.0. As it turns out, the jar file was never being used in the 3.7.2 release either. We always assumed it was but in reality what was happening was that it was using a font from the file system, and NOT the .ttf file packaged in the jar. I found this out month or so back while diagnosing yet another font problem.
So in reality I think what was happening was that the 4.0 version was much stricter with the font, looking for it ONLY in the classpath where it was never found. It seemed like the 3.7.2 version was using the jar file in the class path but it turns out that it was actually finding the font on the local filesystem. So here is the bottom line: USE IREPORT TO GENERATE YOUR FONT EXTENSIONS!
If I create the directory structure and package it up with the jar command manually it fails, regardless of which format/tutorial I follow (which includes the tutorial in the ultimate guide -- as I mentioned before even Jaspersoft support/dev couldn't explain why it didn't work). Generating the jar file using iReport seems to be the only way that the JVM can locate the font definitions in the classpath. I have now generated 2 different jar files this way and both of them have worked on every system in every scenario I have thrown at them. The only time it doesn't work is when it fails to find a font like Garamond or Calibri, but those are fonts that are not supported by default (like the DejaVu fonts), and are not packaged up in our font extension. So I expect them to fail. After running into these issues I simply added to our product documentation a list of supported fonts. If any user strays from that list and has problems we can simply direct them to the documention that says you shouldn't have used that font, and if you insist on using it then you will have to create your own font extension in iReport and add it to the classpath yourself. Thanks to lawyers and so on, we don't have the rights to redistribute anything except for open source fonts. ;)
There is a bug in JR, at least in 4.7.0, You cann't use <font fontName="" size="11" /> because You will get Font '' is not available to the JVM" even with net.sf.jasperreports.awt.ignore.missing.font=true as a workaround register yours any custom font under ""