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 JDK: IBMJDK1.4.1 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 charactesrs. --fonts.dir: original ------------- 227 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- iso10646-1 LucidaTypewriterRegular.ttf -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0- iso8859-1 LucidaTypewriterRegular.ttf -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0- iso8859-15 LucidaTypewriterRegular.ttf -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0- iso8859-10 ... ---------------------------- --fonts.dir after the reboot ----- 167 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- 15 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- 10 ... LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0- 0-m-0-ascii-0 LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0- 0-m-0-fcd8859-15 LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0- 0-m-0-iso8859-1 LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0- 0-m-0-iso8859-10 LucidaTypewriterRegular.ttf -b&h-Lucida Sans Typewriter-medium-r-normal--0-0-0- 0-m-0-iso8859-15 ... ---------------------------- 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. FYI: `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,
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. Reassigning...
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. TIA
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.
------ Additional Comments From chinen.com 2003-21-10 22:19 ------- Nakamura-san, Does my workaround (Comment #2) work for you? i.e. - 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 or, - Make a copy of font directry and use copied directory for xfs. I think currect /etc/init.d/xfs script behavior is reasonable.
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.
------ Additional Comments From toshiona.com 2003-22-10 22:50 ------- I forwarded these RedHat's replies to the owner of PMR62774,001,866. I'm waiting his response. Chinen-san, 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
------ Additional Comments From chinen.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.
----- Additional Comments From chinen.com 2004-01-13 21:35 ------- Nakamura-san, May I close this bug report? RedHat already closed this bug on their Bugzilla.
----- Additional Comments From toshiona.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.