wood burning stoves 2.0*
The moose likes Swing / AWT / SWT and the fly likes font portability Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "font portability" Watch "font portability" New topic
Author

font portability

paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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?


permaculture Wood Burning Stoves 2.0 - 4-DVD set
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
What Look and Feel are you using?
Try looking at this:
http://java.sun.com/products/jfc/tsc/articles/jlf/
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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.


GenRocket - Experts at Building Test Data
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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?
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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.
Alex Ku
Ranch Hand

Joined: Jan 15, 2002
Posts: 47
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.

So, to be safe, using your own font.
kawaii
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Originally posted by Paul Wheaton:
We are using setounds and the null layout manager all over the place.
Well, you identified your problem right there. It is nearly impossible to design a WORA application without using Layout Managers.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
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


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
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.
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
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.
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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
Paul Stevens
Ranch Hand

Joined: May 17, 2001
Posts: 2823
Probably could have been done sooner with a layout manager
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: font portability