Linux Collaboration - font subissue
by Todd "zaz" Koeckeritz · in Torque Game Engine · 02/14/2006 (11:52 am) · 8 replies
This thread is intended to continue the discussion on the font issues from the Linux collaboration there available here.
I assume this is a font you're shipping with the game ? It really only solves one minor aspect of the font issue though, but it would be good if we had a font, a nice scaleable one anyway, that we always knew was there.
Quote:we'd be fine with just shipping at least one valid UFT
I assume this is a font you're shipping with the game ? It really only solves one minor aspect of the font issue though, but it would be good if we had a font, a nice scaleable one anyway, that we always knew was there.
About the author
#2
02/15/2006 (7:53 am)
Busy working on "real" stuff today, :-), so I can't spend much time on torque, but xdpyinfo can get this info from the Xserver, so there must exist a documented API to do this. Grab the source for that if nothing else.
#3
it looked bad on fedora but then when I checked it later it was ok - maybe it picked a different font the next run?
I still think there needs to be some kind of user force-able font mapper through text config file.
I say this because then we could compile one bin and then tweak the font rendering for different distros with a config file.
I was able to put the cvs from 2006-0119 on mephis(the 2006-0119 doesn't compile but 2006-0214 does) and see that the old font method results in a easier to read font ( maybe the old way was too big because some text is clipped ) - this is why i think we need to be able to user tweak the fonts without having to recompile.
It will be easier when you distribute a game and you don't need a separate bin for different distros because the font code doesn't work.
The funny thing is that the horrible to read font on mephis renders ok - everything gets filled in
- f10 there is text across the top, f11 there is text so you can set the transform for trees or healthpacks(etc)
02/15/2006 (8:59 am)
The new font code looks ok on one distro but then looks horrible on simplymephis 334 and I also could swearit looked bad on fedora but then when I checked it later it was ok - maybe it picked a different font the next run?
I still think there needs to be some kind of user force-able font mapper through text config file.
I say this because then we could compile one bin and then tweak the font rendering for different distros with a config file.
I was able to put the cvs from 2006-0119 on mephis(the 2006-0119 doesn't compile but 2006-0214 does) and see that the old font method results in a easier to read font ( maybe the old way was too big because some text is clipped ) - this is why i think we need to be able to user tweak the fonts without having to recompile.
It will be easier when you distribute a game and you don't need a separate bin for different distros because the font code doesn't work.
The funny thing is that the horrible to read font on mephis renders ok - everything gets filled in
- f10 there is text across the top, f11 there is text so you can set the transform for trees or healthpacks(etc)
#4
I agree that their is somethign going on behind the sceens wheh TGE creates the window and SDL Surface, have to runt hrough that could and see what is going on. Could be something as simple as the resolution and bpp being passed, not sure though
-Ron
02/17/2006 (6:38 am)
My current Ubunut system is setup for 96 DPI, which is the DPI of the MS core fonts. I removed the DPI restriction from x86UNIXFont.cc and removed the mSize restriction, the game loads and the fonts are just un godly HUGE.I agree that their is somethign going on behind the sceens wheh TGE creates the window and SDL Surface, have to runt hrough that could and see what is going on. Could be something as simple as the resolution and bpp being passed, not sure though
-Ron
#5
Only reason I mentioned distro (in the other linux Colab forum) is because of your thread were you reported fc-match returning aliased fonts for the MS Core ones. Not sure if every distro is setup like that or if it is a stock KDE/Gnome configuration. These types of issues need to be investigated further to fully understand them.
Font picking/rendering etc is new to me, which leaves me (and possible most if not all of the others) at a disadvantage. We need to really crack open some books and hit google hard to truly understand how font picking/rendering should be done.
I agree that we are doing something within the engine that is causing the fonts to look abnormal when not specifying a dpi (using the native dpi from the font). As stated above, on my ubuntu my dpi is set to 96 (in line with MS core fonts) and yet the fonts are stupidly huge.
02/17/2006 (2:23 pm)
@EddieRay,Only reason I mentioned distro (in the other linux Colab forum) is because of your thread were you reported fc-match returning aliased fonts for the MS Core ones. Not sure if every distro is setup like that or if it is a stock KDE/Gnome configuration. These types of issues need to be investigated further to fully understand them.
Font picking/rendering etc is new to me, which leaves me (and possible most if not all of the others) at a disadvantage. We need to really crack open some books and hit google hard to truly understand how font picking/rendering should be done.
I agree that we are doing something within the engine that is causing the fonts to look abnormal when not specifying a dpi (using the native dpi from the font). As stated above, on my ubuntu my dpi is set to 96 (in line with MS core fonts) and yet the fonts are stupidly huge.
#6
simplyMepis ( is in the top ten of major distributions at distrowatch )
ok fedora core 3 and mandrake have the missing font problem
but mandrake is supposed to be based on fedora
simplyMepis ( debian based ) has an ugly looking font but it's not missing anywhere.
Ubunut is debian based i believe - so i think that's why you don't see the problem.
It would be interesting to see how slackware and gentoo render the fonts...
when I get a hard drive cleaned up i be able to check slackware and gentoo but that may be a long time.
On my stack of things to do, I'll probably check opensuse sometime( just a default install ) since Todd is running suse but hasn't complained about the font.
02/17/2006 (6:10 pm)
@Ron,simplyMepis ( is in the top ten of major distributions at distrowatch )
ok fedora core 3 and mandrake have the missing font problem
but mandrake is supposed to be based on fedora
simplyMepis ( debian based ) has an ugly looking font but it's not missing anywhere.
Ubunut is debian based i believe - so i think that's why you don't see the problem.
It would be interesting to see how slackware and gentoo render the fonts...
when I get a hard drive cleaned up i be able to check slackware and gentoo but that may be a long time.
On my stack of things to do, I'll probably check opensuse sometime( just a default install ) since Todd is running suse but hasn't complained about the font.
#7
I've done too much font stuff in the past writing my own printer drivers and using the Speedo fonts for an old 32 bit dos app (ported to java years ago, thank God, :) ). I'm rusty on specifics, but its not really all that much brain surgery once you boil it down to the basic details .. like most stuff.
@Charles:
I can duplicate the problem on my box (suse 9.3). I've seen it when I was messing with the code in x86UNIXFont.cc and removed the modifications to the point setting and then forced the dpi to my desktop's dpi. Basically, I made the fonts huge.
In most places, say in the demo with the gui buttons, the font was just too big and over wrote stuff or got clipped. When it game to stuff like doing settings in the mission editor (F11 then F3), I wouldn't see text in the lower right part of the screen, like those screenshots that keep getting referenced. However, yeah, under my current desktop of 1600x1200 at 100dpi, Ron's current version of x86UNIXFont.cc provides functional results with the only caveat being that the fonts are smaller than I think they should be.
I think what we have to do here to make this work well is to find or create a virtual/logical frame of reference. This frame of reference would be like my piece of paper for my printer drivers. The paper had hard physical dimensions. The printers had a fixed dpi at which they could print dots. I had a set of scaleable fonts and my own internal interpretation of what I was drawing and how it mapped to the paper. To keep things simple, my internal representation of the data to be rendered was in inches and this was mapped as accurately as possible to the paper.
The important thing to understand here is that I had a fixed frame of reference in the paper. With that fixed frame of reference, I just needed to make all the variables between the internal representation and the paper do the right thing and then those two would match.
Lets take the simpler case of torque being rendered in a window. In this case, the torque window is our paper. The printer here is the graphics system as it determines/tells us the dpi. The fonts are virtually the same. Yeah, there are a few other variables, but if we wrap our heads around this situation, the others should fall into place.
What we need to find or create is the logical/virtual dimensions of the torque window. This might already exist to deal with building the multi-resolution support for GUIs into torque, it might not. If it doesn't we could create one in any dimensions we want, inches, centimeters, tpus (torque pixel units), etc. It doesn't matter, we're just measuring the width and height of the torque window in these logical units.
The other missing piece of information we then need is how the font is picked for the windoze port of tge. Combine that information with the known dpi for the windowing system and the you can either make concrete computations to pick the correct font size for non-scaleable fonts or to choose the correct dpi for your scaleable fonts.
Two possible issues here. First, the application I wrote the printer drivers for generated proposals for life insurance agents to use to sell life insurance. Thus it was very important that we always had as good of a layout as possible under all circumstances ... think of a page layout program like PageMaker. I imagine there'd be less of a demand for this in a game engine and thus the framework for supporting multi-resolution display could easily be much less robust in TGE than it was in my application.
The little GUI editing I've done in TGE shows that some thought did go into this, but I also don't see some of the things I'd expect if this was really extensively supported well. Maybe GG chose to do it differently than I did and its there, but it might not be.
Secondly, we could all just be making this a much tougher problem than it really it. All of the stuff I mention above would have to also be done in the windoze port of TGE. We shouldn't be reinventing the wheel here and duplicating the code they have, heck this would have to be done on any modern system. Unless windoze somehow provides some font stuff that X doesn't, this is almost certainly the case.
In any event, it would be nice if TGE worked as similarly as possible across all supported platforms and shared as much common code as possible. If you ask for a 15 point font under windoze and get a 15 point font under windoze, why shouldn't you get a 15 point font for the same request under linux and OSX ? In all cases, that torque window is sitting there taking up the upper left 75% of the user's desktop. That 15 point font should be the same everywhere, assuming the same font is available.
Anyway, those are my thoughts on this issue at the moment. If I get some time, I'll try to look at this some too, but I'd like to toss some debugging code in a windoze build and see what happens there. Since I haven't gotten mingw working on building TGE under windoze since I installed XP on a test box here, I'm not sure when I can do this though. I need to get mingw building my windoze TGE sometime anyway, it just hasn't been a big priority to me.
02/18/2006 (2:13 pm)
@Ron:I've done too much font stuff in the past writing my own printer drivers and using the Speedo fonts for an old 32 bit dos app (ported to java years ago, thank God, :) ). I'm rusty on specifics, but its not really all that much brain surgery once you boil it down to the basic details .. like most stuff.
@Charles:
I can duplicate the problem on my box (suse 9.3). I've seen it when I was messing with the code in x86UNIXFont.cc and removed the modifications to the point setting and then forced the dpi to my desktop's dpi. Basically, I made the fonts huge.
In most places, say in the demo with the gui buttons, the font was just too big and over wrote stuff or got clipped. When it game to stuff like doing settings in the mission editor (F11 then F3), I wouldn't see text in the lower right part of the screen, like those screenshots that keep getting referenced. However, yeah, under my current desktop of 1600x1200 at 100dpi, Ron's current version of x86UNIXFont.cc provides functional results with the only caveat being that the fonts are smaller than I think they should be.
I think what we have to do here to make this work well is to find or create a virtual/logical frame of reference. This frame of reference would be like my piece of paper for my printer drivers. The paper had hard physical dimensions. The printers had a fixed dpi at which they could print dots. I had a set of scaleable fonts and my own internal interpretation of what I was drawing and how it mapped to the paper. To keep things simple, my internal representation of the data to be rendered was in inches and this was mapped as accurately as possible to the paper.
The important thing to understand here is that I had a fixed frame of reference in the paper. With that fixed frame of reference, I just needed to make all the variables between the internal representation and the paper do the right thing and then those two would match.
Lets take the simpler case of torque being rendered in a window. In this case, the torque window is our paper. The printer here is the graphics system as it determines/tells us the dpi. The fonts are virtually the same. Yeah, there are a few other variables, but if we wrap our heads around this situation, the others should fall into place.
What we need to find or create is the logical/virtual dimensions of the torque window. This might already exist to deal with building the multi-resolution support for GUIs into torque, it might not. If it doesn't we could create one in any dimensions we want, inches, centimeters, tpus (torque pixel units), etc. It doesn't matter, we're just measuring the width and height of the torque window in these logical units.
The other missing piece of information we then need is how the font is picked for the windoze port of tge. Combine that information with the known dpi for the windowing system and the you can either make concrete computations to pick the correct font size for non-scaleable fonts or to choose the correct dpi for your scaleable fonts.
Two possible issues here. First, the application I wrote the printer drivers for generated proposals for life insurance agents to use to sell life insurance. Thus it was very important that we always had as good of a layout as possible under all circumstances ... think of a page layout program like PageMaker. I imagine there'd be less of a demand for this in a game engine and thus the framework for supporting multi-resolution display could easily be much less robust in TGE than it was in my application.
The little GUI editing I've done in TGE shows that some thought did go into this, but I also don't see some of the things I'd expect if this was really extensively supported well. Maybe GG chose to do it differently than I did and its there, but it might not be.
Secondly, we could all just be making this a much tougher problem than it really it. All of the stuff I mention above would have to also be done in the windoze port of TGE. We shouldn't be reinventing the wheel here and duplicating the code they have, heck this would have to be done on any modern system. Unless windoze somehow provides some font stuff that X doesn't, this is almost certainly the case.
In any event, it would be nice if TGE worked as similarly as possible across all supported platforms and shared as much common code as possible. If you ask for a 15 point font under windoze and get a 15 point font under windoze, why shouldn't you get a 15 point font for the same request under linux and OSX ? In all cases, that torque window is sitting there taking up the upper left 75% of the user's desktop. That 15 point font should be the same everywhere, assuming the same font is available.
Anyway, those are my thoughts on this issue at the moment. If I get some time, I'll try to look at this some too, but I'd like to toss some debugging code in a windoze build and see what happens there. Since I haven't gotten mingw working on building TGE under windoze since I installed XP on a test box here, I'm not sure when I can do this though. I need to get mingw building my windoze TGE sometime anyway, it just hasn't been a big priority to me.
#8
It's getting to this point:
Loading compiled script common/ui/LoadFileDlg.gui.
Could not locate texture: common/ui/bs
% Segmentation fault
And XftFontOpenName at line 245 in x86UNIXFont.cc is returning a null at that point causing the AssertFatal. This same binary runs fine on a fedora core 3 box. The fonts are pretty much the same on both boxes. It seems to happen when it tries to load up a GuiButtonProfile.
Any ideas?
05/01/2006 (4:32 am)
I'm having problems with a stock install of fedora core 5. It's getting to this point:
Loading compiled script common/ui/LoadFileDlg.gui.
Could not locate texture: common/ui/bs
% Segmentation fault
And XftFontOpenName at line 245 in x86UNIXFont.cc is returning a null at that point causing the AssertFatal. This same binary runs fine on a fedora core 3 box. The fonts are pretty much the same on both boxes. It seems to happen when it tries to load up a GuiButtonProfile.
Any ideas?
Associate Ron Yacketta
turned off the dpi request from the font query string, it now pulls back a 96dpi windows font which is f'ing HUGE! (which is what I expected), I got the font fitting the widgets, but the size was around 6 ;)
What I did find to be a decent combo was a dpi of 75 using the same font scale (sizing) int mSize = size - 2 - (int)((float)size * 0.1);
Give that a try and tell me what you think.. looking for a way to checks the end users setup for dpi, not sure if it would be a X check or a fontconfig type check.. time to hit google and see what s/he reports
-Ron