Bug 107663 - LTC5037-Java's fonts.dir file was broken if xfs sets java fonts
LTC5037-Java's fonts.dir file was broken if xfs sets java fonts
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ttmkfdir (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Yu Shao
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-10-21 15:59 EDT by IBM Bug Proxy
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-22 12:22:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description IBM Bug Proxy 2003-10-21 15:59:16 EDT
The following has be reported by IBM LTC:  
Java's fonts.dir file was broken if xfs sets java fonts
Hardware Environment:
PC (PentiumIII 1G, Memory 256MB)

Software Environment:
Operating System:  RHAS2.1, RHEL3.0RC4

Problem Description:
Java's fonts.dir and fonts.scale files were broken if xfs sets java fonts on 
RHAS2.1. If the problem occurs, Java cannot show any alphabet characters.

Steps to Reproduce:
1. Install IBM JDK1.4.1.

2. Add the java fonts' directory to xfs by root user.
# chkfontpath -a /opt/IBMJava2-141/jre/lib/fonts

3. Reboot the system (or restart xfs).

Actual Results:
/opt/IBMJava2-141/jre/lib/fonts/fonts.dir and fonts.scale were changed at the 
time. With the new fonts.dir/fonts.scale, Java cannot show any alphabet 

--fonts.dir: original -------------
tnrwt_j.ttf -monotype-timesnewromanwt-medium-r-normal--0-0-0-0-p-0-iso10646-1
tnrwt_j.ttf -monotype-timesnewromanwt-medium-r-normal--0-0-0-0-p-0-iso8859-15
LucidaTypewriterRegular.ttf -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0-
LucidaTypewriterRegular.ttf -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0-
LucidaTypewriterRegular.ttf -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0-
LucidaTypewriterRegular.ttf -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0-

--fonts.dir after the reboot -----
LucidaBrightDemiBold.ttf -b&h-Lucida Bright-bold-r-normal--0-0-0-0-p-0-ascii-0
LucidaBrightDemiBold.ttf -b&h-Lucida Bright-bold-r-normal--0-0-0-0-p-0-fcd8859-
LucidaBrightDemiBold.ttf -b&h-Lucida Bright-bold-r-normal--0-0-0-0-p-0-iso8859-1
LucidaBrightDemiBold.ttf -b&h-Lucida Bright-bold-r-normal--0-0-0-0-p-0-iso8859-
LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0-
LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0-
LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0-
LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0-
LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0-

Expected Results:
The fonts.dir/fonts.scale were not changed. Java can use these '-jdk-*' fonts 
via xfs.

Additional Information:
I did open this problem to Java team as PMR62774,001,866 at first, and they 
determined it's RedHat's problem. They said, Java set and expected these fonts' 
names were '-jdk-*'. Nobody should change these fonts' name.

The problem occurs with all current JDKs, such as IBMJDK1.3.1, 1.4.1, Sun 
JDK1.3.1, 1.4.1, 1.4.2.

It still occurs on RHEL3.0RC4.

The Java's fonts have better quality than the system fonts in some case for 
Java. So, we'd like to set them to xfs. I think it's a valid operation.Greg/Glen
- please submit this to Red Hat.
Chinen-san - do you have any insight on this issue ?
Thanks.This problem is caused by ttmkfdir, which rewrites fonts.scale.

In /etc/init.d/xfs script, ttmkfdir and mkdfontdir are executed.
ttmkfdir creates font.scale in the directory defined by chkfontpath.
At that time, ttmkfdir defines foundry and family name with refering
the vendor information which is embeded in ttf font.
Java developers seem to define the foundry and family name with their
own way. Therefore, fonts.scale produced by ttmkfdir would differ from
fonts.scale included in Java package.

  `foundry' shows the name of font creator.
  `family name' shows the name of font type. 

For example, the foundries of fonts from LucidaTypewriterRegular.ttf are
defined as `jdk' in Java packages's fonts.scale. However, the information
embeded in ttf file says the font vendor is 'b&h'. There are no string `jdk'
in the embeded information. Therefore, ttmkfdir cannot set `jdk' into foundry.
It sets `b&h' into foundry.

I would rather tell you that Java lacks flexibility in handling fonts.
But, as Java developer says "Nobody should change these fonts' name",
we should consider it is designed behavior.

A workaround is to execute the following command before you make xfs restart.

  touch -m /opt/IBMJava2-141/jre/lib/fonts/fonts.dir

However, I recommend you making a copy of the font directory and using
the copied directory for xfs, if anything.

Thank you,
Comment 1 Mike A. Harris 2003-10-21 17:34:34 EDT
Red Hat official font package installation policy dictates that fonts.scale
and fonts.dir files MUST NOT be installed statically by any rpm package.  We
can only enforce that for packages that we supply however, we can not force
externally supplied font packages to follow our internal policies, although
we highly recommend it.

Our xfs initscript intentionally looks through the directories in the configured
xfs font path for font files installed which are newer than the fonts.dir file
in the font directory, and it intentionally reprocesses that font directory
by calling ttmkfdir and mkfontdir as appropriate for the font type in question.

This ensures that if a user drops fonts into the font directories, that a
restart of the xfs initscript or a system reboot will autoregenerate any
of the font metadata files automatically and "just work" without any required
user hand munging of the files.  This process makes the end user experience
of font handling much much better and reduces the number of bogus incoming
font related bug reports and technical support phonecalls, etc.

If there is a pre-prepared fonts.scale file which differs from the one that
ttmkfdir generates, this indicates either:

1) A bug in ttmkfdir, or 2) A missing feature in ttmkfdir (such as missing
foundry name or somesuch), or 3) Broken fonts or font metadata stored in the
fonts.   There may also be other problem scenarios also perhaps.

Either way though, the xfs initscript does and always will regenerate
fonts.scale and fonts.dir.  The current rawhide xfs initscript is dramatically
improved, as is the current rawhide ttmkfdir.  It is at least theoretically
possible that these might solve the problem perhaps, but that would need
confirmation first.

Since this isn't a bug in the xfs initscript, nor in anything in XFree86
itself per se IMHO, it's more appropriate to reassign this to the ttmkfdir
component for now as that is the most likely culprit aside from bugs in the
fonts themselves.

Comment 2 Mike A. Harris 2003-10-21 17:36:48 EDT
Yu:  Can you investigate this and determine if this is a real bug or flaw
in ttmkfdir, a bug in the fonts, or in their installation, or something else?
ttmkfdir is the most likely culprit here.

It might be a good idea to also test the output of mkfontscale too.

Also might be useful to try the xfs initscript from rawhide.

Comment 3 Yu Shao 2003-10-21 21:36:25 EDT
The foundry name used by ttmkfdir as well as mkfontscale is provide by the font
file itself, it is in font file header. If you need to use the foundry name,
then "b&h" is the one, we can not change it.

If these fonts are exclusive to JDK, I think changing the header set the foundry
name to "jdk" would do.
Comment 4 IBM Bug Proxy 2003-10-21 22:22:30 EDT
------ Additional Comments From chinen@jp.ibm.com  2003-21-10 22:19 -------

Does my workaround (Comment #2) work for you?

- Make the modification time of fonts.dir newer than ttf files
  before you restart /etc/init.d/xfs script.
    # touch -m /opt/IBMJava2-141/jre/lib/fonts/fonts.dir
- Make a copy of font directry and use copied directory for xfs.

I think currect /etc/init.d/xfs script behavior is reasonable. 
Comment 5 Mike A. Harris 2003-10-22 12:22:40 EDT
The xfs initscript needs to remain generic for maintainability.  I won't
introduce per-special-font or per-special-directory hacks into the initscript.

If this causes a problem for some applications/fonts/etc. then IMHO, there is
either a bug in the ttmkfdir application, or a bug in the font itself.
Either the font needs to be fixed or ttmkfdir needs to be fixed.  Yu Shao's
comment seems to indicate that ttmkfdir is doing the correct thing here, and
so I believe that the font is buggy, or that Java, etc. is abusing them and
expecting some specialized/customized behaviour to occur which isn't realistic.

It is possible that a fonts.alias file provided with the fonts might
provide a workaround until someone can fix the fonts themselves perhaps.
Comment 6 IBM Bug Proxy 2003-10-22 23:20:12 EDT
------ Additional Comments From toshiona@jp.ibm.com  2003-22-10 22:50 -------
I forwarded these RedHat's replies to the owner of PMR62774,001,866.
I'm waiting his response.

Thank you for providing us the ideas of workaround. Yes, the first one is valid 
workaround for Java. If either RedHat or Java won't fix the problem, we will 
try to document the workaround.
> - Make the modification time of fonts.dir newer than ttf files
>   before you restart /etc/init.d/xfs script.
>     # touch -m /opt/IBMJava2-141/jre/lib/fonts/fonts.dir 
Comment 7 IBM Bug Proxy 2003-10-28 05:20:36 EST
------ Additional Comments From chinen@jp.ibm.com  2003-28-10 05:19 -------
I'd like to change the status into `Tested' as I proposed workarounds and
Nakamura-san confirmed one of my workarounds. 
Comment 8 IBM Bug Proxy 2004-01-13 22:01:49 EST
----- Additional Comments From chinen@jp.ibm.com  2004-01-13 21:35 -------

May I close this bug report?
RedHat already closed this bug on their Bugzilla. 
Comment 9 IBM Bug Proxy 2004-01-13 22:57:02 EST
----- Additional Comments From toshiona@jp.ibm.com  2004-01-13 22:43 -------
It seems we have no choice but to close this. I've sent the request to Java 
side again. But, it looks difficult. I think guiding the workaround in README 
would be reasonable.

Thank you for your support. 

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