Jump to content

Mac OS X Leopard Font Problems


lps540

Recommended Posts

I am having a problem with the appearance of Arial (and other) fonts when I print from Jasper using my Mac. When I use a pure Java (i.e., non-Jasper program) to print out the same fonts, it works fine. This problem also appears in Intellij, iReport, Netbean, so it is not a Jasper-only related problem. The problem appeared when I upgrade my Mac from Tiger to Leopard. The weird thing though, is why does it work from a pure Java program?

 

I have read about the Apple JVM automatically deciding to use Quartz or not so it must be occuring even if the UseQuartz property is set. I think this is an Apple problem but I thought I would post anyway just it case someone has a magic solution.

 

I am using:

Mac OS X Version 10.5 (Leopard)

Java version "1.5.0_13"

 

As you can see in the test, setting the following property -Dapple.awt.graphics.UseQuartz to true or false makes no difference.

 

Thanks,

Larry [file name=allfiles.txt size=8053]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/allfiles.txt[/file]

Link to comment
Share on other sites

  • 1 month later...
  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

After further research I have found that the UseQuartz property does have an effect. In particular if the program is started with,

 

Code:
-Dapple.awt.graphics.UseQuartz=true

 

then screen rendering breaks as well as print outs. To be more specific, with UseQuartz set to true, the following code also generates reports with incorrect fonts on OS X Leopard:

 

Code:
[code]JRPrinterAWT.printPageToImage(...)

 

When the settings is set to false instead as in,

 

Code:
[code]-Dapple.awt.graphics.UseQuartz=false

 

then the generated images come through right but print outs still exhibit the problem. So as a simple guess, it appears that the Quartz rendering pipeline is a part of the problem and that it cannot be turned off when printing.

Post edited by: aljungberg, at: 2008/01/22 22:39

Link to comment
Share on other sites

  • 2 weeks later...

I now have a report that printing in Panther is not solid either. One tester reported seeing his print degrade in quality like if the DPI sent to the printer was incorrect. This was on a fairly standard Epson Inkjet.

 

The problems are distinct in their nature (Leopard prints have the right resolution but incorrect fonts, this Panther printer has the right fonts but incorrect resolution) but I thought I'd make a note of this here in case the print path in general has difficulties on the Mac.

 

Has anyone heard of similar reports?

Link to comment
Share on other sites

  • 3 weeks later...

I have been discussing this problem on the apple java dev mailing list and a sharp fellow by the name of Bernd Gründling posted the following "hack" which "fixes" this problem.

 

In

Code:
net.sf.jasperreports.engine.export.TextRenderer#renderParagraph ( AttributedCharacterIterator allParagraphs, int lastParagraphStart, String lastParagraphText)

replace the line ...

 

Code:
[code]draw(layout);

 

with the following...

 

Code:
[code]// I am trying to fix printing problems under Leopard,
// where fonts get not set properly.
// I am checking the OS Version, maybe I should check
// the JRE release instead.
// This has to be amended when the bug in whatever
// library has been corrected.
// Hopefully I have covered all malfunctioning system versions.

if (System.getProperty("os.name"«»).equals("Mac OS X"«») && System.getProperty("os.version"«»).startsWith("10.5"«»))
{
paragraph.setIndex(paragraph.getBeginIndex());
grx.setFont(Font.getFont(paragraph.getAttributes()));
}

draw(layout);

 

 

There seems to be a "bug" somewhere in apple's code which causes the font not to be set in the graphics context properly. Therefore by setting it forcibly with a grx.setFont(f), we solve the problem. Without doing this, the character placement is done using the correct font, but the font that is printed is always Lucida Grande 12.

 

I'm not suggesting that this hack is pretty and should be used as is to solve the problem. I'm just passing on the wisdom from some of the smart people on the apple java dev mailing list such as Bernd Gründling, Peter Mycue, and others who are discussing this issue and trying to get it solved quickly.

 

Please note that I have filed a bug with Apple regarding this issue. However, judging by how quickly Apple has moved in the past to fix such issues, I'm hoping we can get a proper fix worked into the jr libs more quickly. Please post this hack as additional info on the bug you filed.

 

Cheers.

 

-Raffi M.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...