Right Outer Join

16 April 2010

Fonts in JasperServer 3.7

Filed under: JasperServer — Tags: , , , , , , — mdahlman @ 12:05

You can’t display fonts that you don’t have

The Problem

I have written about fonts in JasperServer in the past, but I’m revisiting it now. It’s popular topic because fonts are very important to the look of your reports, but it’s easy to get things setup wrong (or incompletely). Let’s start with the “Sales by Month” report which ships with JasperServer Professional and Enterprise 3.7.

Sales by Month report in Japanese

Sales by Month report in Japanese

Let me be the first to say, “Hey! didn’t those Jaspersoft guys improve anything in v3.7? Why doesn’t my chart correctly display the legend characters in Japanese by default!?”

The Solution

The issue—as is common with font issues—turns out to be more subtle than one might expect. First we have the somewhat confusing situation that some Japanese characters display well. It’s only the chart that has a problem. This is because my local Windows XP machine has appropriate Japanese fonts. So things like this render nicely: “キー:  低い値    高い値”. That’s because they get rendered by my browser. But the chart gets created on the server. A bad choice of font must be happening there.

In JasperServer v3.5 the problem was that the report specified Verdana as the font. Verdana doesn’t include glyphs for Japanese characters, so it wasn’t really JasperServer’s fault that it couldn’t render things well. It was the report designer’s fault. In JasperServer v3.7 all of the sample reports have been updated to use Java logical fonts like SansSerif, Monospaced, etc. This means that JasperServer pushes the job of selecting the exact physical font down to the JVM which works with the underlying OS to find an appropriate font.

Aha! this means we have a new culprit to point fingers at: Java. What font is the JVM deciding to use? I’m running JasperServer in the cloud on a CentOS Linux box. What font faces are available? Let’s see:

# fc-list
#

That’s right. No fonts at all are available. That is likely the root of my problem. Are there fonts available to install? Let’s see:

# yum list | grep japanese
fonts-japanese.noarch                    0.20061016-4.el5       base
m17n-db-japanese.noarch                  1.3.3-48.el5           base

There are fonts available. It takes only a few seconds to install them:

# yum install fonts-japanese.noarch

Now I have lots of fonts available:

# fc-list
fxd:style=Bold semicondensed
sys:style=Bold
hlv:style=Bold Italic
Fixed:style=Bold
goth_p:style=Bold
sys:style=Bold Italic
...

Finally, I need to restart Tomcat. Now when I log back into JasperServer I see everything rendered correctly. Woo hoo! The report was good. JasperServer was good. Tomcat was good. Everything was good… except the underlying operating system didn’t have any appropriate fonts.

Sales by Month report in Japanese

Sales by Month correctly displaying all Japanese characters

Other Fonts

What about when you want to specify the precise font that you need? That’s a good question. I ignored it in this article. The short answer is that you need to use Font Extensions. I wrote about it previously in my article “Fonts in JasperServer“.

In general the use of Java logical fonts makes things more flexible. That’s what made it the ideal choice for sample reports that ship with JasperServer. But it’s possible that different systems will map the logical fonts to different physical fonts. These fonts may have slightly different metrics, so the results in the report can be slightly unpredictable.

In many reports, you simply don’t care about the minor font metric differences. On one machine a particular value fits on a single line. On another machine it overflows into a second line. So what?

In other reports you have more precise positioning requirements. Your title fits nicely on a single line at design time. But when the report is deployed the final word in the title overflows into a second line. That won’t look impressive. Worse: that field isn’t allowed to expand, so you don’t see the final word anywhere. Bummer. In cases like this you need to specify the precise font that gets used. Of course it therefore becomes your responsibility to make sure that the server has the font that you want to use. For these situations Font Extensions are your savior.

Advertisements

4 Comments »

  1. […] Shared Fonts in JasperServer 3.7. […]

    Pingback by Frau Klein im Internet during the week | kerstins kleiner blog — 19 April 2010 @ 12:10

  2. […] folks should refer to my updated article on Fonts in JasperServer 3.7 instead of the article below. But I’m leaving the old article here for cases where someone […]

    Pingback by Fonts in JasperServer « Right Outer Join — 11 May 2010 @ 16:00

  3. Thanks for the informative article!

    I have a question for you though: do you know if it’s possible to define multiple font families for the pdf exporter (in a similar manner to how you’d define fonts to use in a css tag) in order to support as wide a character range as possible?

    We have customers all over the world and I can’t figure out how to make the pdf exporter look at say Font A for Latin characters, Font B for Chinese, C for Japanese etc. In other words, I want to make a font jar with all these font families packed in so that when the pdf is generated, iText will look at Font A and if the character does not exist there then it will look at Font B, then C, D, E etc…I guess it’s similar to the FontSelector method in iText.

    I’m using JasperServer 5.5 with JasperSoft Studio. Is what I’m trying to do even possible?

    Comment by M — 8 October 2014 @ 11:13

    • What you are talking about makes perfect sense. I wanted to do exactly that myself. When I wrote this article (4.5 years ago!) it was not possible to do this. I had confirmation direct from Teodor back then. But there was no fundamental reason it would be impossible; it was a reasonable improvement idea.
      I don’t know whether it’s possible now. But you ought to be able to get a good answer on jaspersoft.com.

      Comment by mdahlman — 8 October 2014 @ 20:15


RSS feed for comments on this post. TrackBack URI

Go on... leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: