java/76658: font.properties actual font file cannot point to a symlink

Clive Lin clive at tongi.org
Thu Jan 27 11:17:15 PST 2005


On Wed, Jan 26, 2005 at 02:30:26AM +0000, Jiawei Ye wrote:
>  I don't use ttfm.sh actually, they are for XTT and I use FreeType. I use 
>  ttmkfdir from the ports collection.

So did I. In xorg, XTT is deprecated.

I'd say that ttmkfdir isn't actually required either. Xorg can just
handle it well. At this point, those port still use ttfm.sh during
installation should be fixed.

>  2 worthy notes here:
>  
>  1. Applets had always worked, it's the standalone JVM that b0rks all the 
>  time. http://www.chinatimes.com.tw displayed correct Chinese characters 
>  while the SwingSet2 demo displayed blank boxen (JFileChooser demo)

I'm not sure if we're talking about the same root cause, but the
result is same.. :p Wrong fonts.dir and symbolic linked font both
result in same problem.

>  2. Distributied font.properties.zh_TW has the last line pointing to 
>  /usr/local/share/fonts/TrueType/bsmi00.ttf. If the path is a symlink, in my 
>  case linked to /home/local/share/fonts/TrueType/bsmi00.ttf, the JVM will not 

The bsmi00.ttf is part of zh-arphicttf port, which doesn't try to
create the symbolic link. As to fonts installed via ports and jdk
installed via ports, it should work just fine as-is. To my best
knowledge we have 2 possible solutions here:

1. fix jvm .
2. get rid of truetype font dependency in font.properties.zh_TW.

I can't help with #1. As to #2, it "should" be possible.

>  find the proper font file and resulted in blank boxen too. So the problem 
>  lies in the JVM code either when trying to find the properties file or when 
>  trying to locate the actual font file.


Cheers,
-- 
Clive Tong-I Lin | http://tongi.org | PGP KeyID: A008C03E


More information about the freebsd-java mailing list