I'm working on a GUI project and we're having some issues with fonts between running the app on windows and linux. I develop on windows... get it looking sharp.... move it to linux and it looks like crap. The guy I'm working with develops on linux, gets it looking sharp, moves it to windows and it looks like crap. Everything is lightweight so we shouldn't have these problems. It seems tied to the fonts. Are the fonts in Java not the same? Does java use system fonts for even lightweight stuff? If so, is there a font we can grab and use throughout our app so it will always look the same for any O/S?
More info.... We're using a lot of anti-aliasing. And the big problem comes from when we try to ask how many pixels long a string is going to be. Some algorithms seem to work okay on Linux. And some seem to work okay on Windows. But we have yet to find something that works okay on both. It seems like the whole "write once run anywhere" is falling apart on just the font thing. Oh yeah - I'm using JDK1.3
I had your same problem a while back. And what I found out was that even though JAVA is code once, run anywhere, there can still be problems with things like Font. Linux or rather the XWindows subsystem renders their graphics differently than windows. And sadly, not nearly as well either. The only thing I could suggest is make sure you are using Layout Managers everywhere and not using setBounds() anywhere. That can kill you. Sorry I don't have a solution for you, but just thought I would add my two cents. Also, as Cindy mentioned, the Look and Feel will make a difference. Depending on whether you are usuing the Systems Default Look and Feel or specifiying one. For instance, I "think" the default System L&F on KDE is Motiff (which I think is ugly) where as in Windows it is the Windows Look and Feel. Myself, I always use the Metal Look and Feel because it is supported on both platforms. It seems to work best for me.
The stuff in question all inherits container and component. We are also using the null layout manager. So I would think that the look and feel stuff does not come into play. Most of the font stuff is where we specify a commonfont: public static Font commonFont = new Font( "Dialog" , Font.BOLD , 18 ); And yet it seems to behave differently on different systems. I did find this link interesting: http://www.eteks.com/pja/en/ It seems to indicate that a great deal of the java graphics stuff is still system dependent and they are offering a way around that. Anybody familiar with it?
We are using setounds and the null layout manager all over the place. We could write a layout manager, but I don't think that would help since we would still be getting bogus information in trying to calculate placement. The biggest problem we are experiencing is when we say "how long will this string be using this font?" and with that information, we will do the proper setBounds(). But it turns out that the drawn string (with that font) takes up eight pixels more than what it said it would. Sometimes. Dammit! So it seems we need to wrap our heads around this slippery font issue.
check out this link from sun's website, Font Overview If you are using logical name for the Font, like Dialog, MonoSpaced, etc, they are not the physical fonts installed in the system. The Java runtime will map this name to to some physical fonts in the current system. So it will vary from machine to machine, if they have different fonts.
Hello Paul (and any other null Layout Users), I've started a thread called null Layout Users Anonymous for users of null Layout to gather and feel comfortable discussing null Layout. It's ok. You're not alone. There is hope. You can stop if you want to. Good Luck, -Dirk Schreckmann
The problem I am experiencing has nothing to do with the null layout manager. The problem would be the same if I was using a layout manager. The problem has everything to do with fonts. I'm going to try the lucinda font and see if that helps. Apparently, it is part of Java and not the O/S.
Joined: May 05, 2000
Originally posted by Paul Wheaton: The problem I am experiencing has nothing to do with the null layout manager. The problem would be the same if I was using a layout manager.
A layout manager would set the size of the fields so that the fonts would not be an issue. If the font is a different size on a different PC then the layout manager will automatically resize the fields to take this into account.
The layout manager know what size to choose because it extracts the information about that particular string with that particular font. If it gets bad information back, it too will make bad layout choices.
Joined: May 05, 2000
Originally posted by Paul Wheaton: The layout manager know what size to choose because it extracts the information about that particular string with that particular font. If it gets bad information back, it too will make bad layout choices.
I have never encountered a problem with font sizes using layout managers.
Just because you have never seen a million dollars, doesn't mean it doesn't exist. Under normal conditions, this has not been a problem for me either. But now, we are trying to really squeeze some text into a small space, and the problem pops up. As it turns out, the problem is solved. Using some of the glyph information, we are getting much more accurate data back about text and the fonts. Now our stuff is working, and we continue to use the null layout manager. see java.awt.font.GlyphVector