Hi. On 18/04/2011 00:29, Paul Wise wrote: > OpenJDK doesn't have any defoma backend so it is highly unlikely that > defoma has anything to do with this.
I did some more testing and can confirm your sentence: what OpenJDK uses of the package sun-java6-fonts is just that it exposes via some symlinks a few fonts (from the Lucida family) that are in a private directory of Sun VM. Copying those TTFs somewhere (like /usr/local/share/fonts or ~/.fonts), removing sun-java6-fonts and trying Josm with some Thai writings appears to work well. > It appears that paths to fonts are hardcoded in these files: > > /etc/java-6-openjdk/fontconfig.* > /usr/lib/jvm/java-6-openjdk/jre/lib/fontconfig.* These files don't appear to have any reference at all to some Lucida font. Thus there must be something hardcoded or configured somewhere else. Moreover, the problem doesn't appear to be full-path vs. logical name (resolved dynamically), because OpenJDK actually seems to be able to find the font even in /usr/local/share/fonts or ~/.fonts. Then the question turns out to be: who is convincing OpenJDK that it has to use Lucida to display Thai glyphs, instead of using one of the other available fonts? I'll try to investigate it more. > Despite the name these appear to have nothing to do with the standard > method for finding fonts on Linux (fontconfig): > > http://download.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html > http://www.freedesktop.org/wiki/Software/fontconfig > > This OLPC bug seems to explain the situation well: > > https://dev.laptop.org/ticket/8348 > > Probably OpenJDK upstream needs to gain support for using fontconfig > to dynamically find fonts on Linux. This would be a great thing. Thanks for your help, Giovanni. -- Giovanni Mascellani <mascell...@poisson.phc.unipi.it> Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org
signature.asc
Description: OpenPGP digital signature