Bug 478480 - TextLayout constructor depends on fonts to not throw Error
TextLayout constructor depends on fonts to not throw Error
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: java-1.6.0-openjdk (Show other bugs)
5.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: jiri vanek
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-30 15:22 EST by Noa Resare
Modified: 2010-11-24 09:19 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-16 05:14:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a short test program calling the TextLayout constructor with default arguments (470 bytes, text/x-java)
2008-12-30 15:22 EST, Noa Resare
no flags Details
Proposed solution (585 bytes, patch)
2010-07-30 04:09 EDT, Paballo
no flags Details | Diff

  None (edit)
Description Noa Resare 2008-12-30 15:22:49 EST
Created attachment 327976 [details]
a short test program calling the TextLayout constructor with default arguments

Description of problem:
I use apache batik to render svg files into png files on a web server. When using openjdk my rendering fails due to the use of java.awt.font.TextLayout whose constructor expects system fonts.

Version-Release number of selected component (if applicable):
java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2

How reproducible:
always

Steps to Reproduce:
1. Verify that 'rpm -qa|grep fonts' turns out empty, and there are no fonts on your el5 system
2. Compile and run the attached program.
3.
  
Actual results:
An 107 lines long stack trace starting with

Exception in thread "main" java.lang.Error: Probable fatal error:No fonts found.
        at sun.font.FontManager.getDefaultPhysicalFont(FontManager.java:1088)


Expected results:
Successful execution of the program.

Additional info:
when running it using jre-1.6.0_11-fcs from java.sun.com or when running the openjdk version on a workstation with full X/gnome setup the test program executes without any errors
Comment 1 Noa Resare 2009-04-02 09:19:45 EDT
This problem still persists in java-1.6.0-openjdk-1.6.0.0-0.25.b09.el5 from the recent 5.3 release

I have found that installing 'liberation-fonts' solves this problem, so adding a dependency on that package seems like a simple and effective solution.
Comment 2 man lung wong 2010-07-08 14:06:33 EDT
I can verified that by adding:

Require: liberation-fonts 

to openjdk spec file does solve this bug.

Man Lung Wong
Comment 3 Pavel Tisnovsky 2010-07-09 11:37:07 EDT
Martin Matejovic have created new OpenJDK RPMs which now properly check if liberation-fonts is installed. I'm going to run our tests against these new unofficial RPMs.
Comment 6 Paballo 2010-07-30 04:09:35 EDT
Created attachment 435492 [details]
Proposed solution

Try this Patch
Comment 8 Ondřej Žižka 2010-10-26 19:19:56 EDT
*** Bug 647054 has been marked as a duplicate of this bug. ***
Comment 9 Ondřej Žižka 2010-10-26 19:22:27 EDT
Reproduced with IcedTea 1.7.4 - see the duplicate above.
Comment 10 Ondřej Žižka 2010-10-29 10:20:24 EDT
Linked from https://jira.jboss.org/browse/JBPAPP-5338
Comment 11 jiri vanek 2010-11-16 05:14:52 EST
I don't think this is bug. How can you expect correct behavior of text components when you remove all fonts?

Note You need to log in before you can comment on or make changes to this bug.