The unicode character \\u2588 is not shown as expected in pdf export from JasperReport object.
But first I to describe my environment: I work with JasperReports 3.7.2, JasperServer 3.7.0,
iReport 4.0.0 and glassfish v3 Prelude on an windows xp system. On the glassfish run's a java
With iReport I created a simple report with one text field. The Text Field Expression is
"Font name is DejaVu Serif: \\u2588", Pdf Font name is Helvetica, Pdf Embedded is false, Pdf Encoding is CP1250. With the unicode character \\u2588 I simulate an bar chart.
The report works fine in iReport, e.g. the character \\u2588 is shown in html and pdf as expected. After publishing
the report to JasperServer via iReport and run the report with the JasperServer UI it works fine too. The character
is shown in html and pdf as expected.
Inside the web application the report is generated via the web service. An JasperPrint object is return from
JasperServer to the client. Afterwards the JasperPrint object is exported to pdf via the JRPdfExporter. In this
pdf document the character \\u2588 is replaced with an question mark "?"! Why?
I have debug the web application to check the availability of the font "DejaVu Serif" with the code
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames() and it is present on the jvm context.
Has anybody an idee how I do isolate or fix the problem.
Surely you noticed that the property is not called "PDF Font Name" in iReport. It is called "Pdf Font name is now deprecated. You should use a Font extension when using a not standard font. See Tools->Options->Fonts."
Don't use "PDF Font Name".
Use Font Extensions.
These are explained in docs and in samples and in other posts. Here's one post.
Matt, thank for your reply.
I red your post Jaspersoft Font Extensions bevor I wrote this topic. But I think this is not the problem.
The web appl. is running on glassfish and the JasperServer is running on tomcat. So, my report
generation process is as follows:
The web appl. request's the JasperServer via web services to get the report. The JasperServer fill the report and
send an JasperPrint object back to the web appl. The web appl. exports the report into pdf, e.g. the exporting process
(jasperprint -> pdf) is done inside the web appl. and not inside of JasperServer.
The Font Extension you describe has an effect on JasperServer and not on glassfish, right?
If I run the report via JasperServer UI and export it to pdf the character \\u2588 is shown as expected. This is
correct, because the Font Extension is installed on JasperServer.
Did you understand my problem or do you need more information?
That's indeed strange.
But the font extension isn't a JasperServer feature. It's a JasperReports feature. Therefore it applies to your web application in Glassfish as much. Export DejaVu Serif as a font extension from iReport (from the font extensions section in the preferences). Then add this .jar file to your application. It may solve it.
I'm not super confident... because you already have the font available to the JVM. So perhaps something sneakier is at work. But you should start with this; it should be a quick test.
I added the *.jar file to glassfish (../domains/domain1/lib) and it works as I expected. Thank you for the hint.
But the following fact I don't understand: I have debug the web application to check if the used font is available
inside the JVM with code like "java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames()" and it was present. Normally, the iText pdf library should use the the fonts visible inside the JVM context. Are you agree with me?
Do you have additional docs or links about this topic?
What environment do you use for testing and debugging JasperReports and JasperServer topics?
Thanks for your feedback.
First, I'm glad it's working well now.
"Normally, the iText pdf library should use the the fonts visible inside the JVM context. Are you agree with me?"
No, I don't agree. But I don't disagree either. ;-)
Your understanding seems completely reasonable to me. But I don't know if that's really how things work. Based on your own tests, it seems that's not how things work. I don't know if that's a weird iText bug or if it's intended behavior. The exact meaning of a font being "installed" or "available" or the TTF being on the machine is beyond what I know.
There's no quick answer to your environment question. We test in lots of different environments.