Linux fonts [0.9]

[kbluck]

0.9 SVN r1791.

I noticed that under Linux/Freetype the font provider basically has a TTF font filename hardcoded to some variation of "Free", which is available by default on my Ubuntu 8.04 but not my OpenSuse 11.

I believe the usual method of font matching on Linux/OSX is to use the "fontconfig" library. Is this already in the works, or would you like me to make an attempt at patching it? Naturally, it will introduce a new dependency, but one that nearly every X11-based distro already uses to manage system fonts; both OpenSuse and Ubuntu have it preinstalled by default, for example. fontconfig also depends on Expat as well, which again is pretty ubiquitous. This won't affect Win32 at all, where you don't seem to be using FreeType anyway.

There's also the Xft library which wraps both fontconfig and FreeType, but since you've already gone to the trouble of coding to FreeType directly I don't think you really need that.

Also, is there any reason you'd want to limit yourself to TTF? FreeType should open just about any sort of font file transparently.

--- Kevin

[kbluck]

I went ahead and patched it to use fontconfig. Patch file attached. I hope I got the autoconf stuff right.

It does a pretty good job of matching arbitrary common font names to actual installed font files. I verified that the FreeType will indeed load PS Type 1 fonts if fontconfig decides that's a better match.

I wasn't able to translate all of the CreateFont-centric parameters, but I made a stab at weight and slant. However, it seems like params are getting offset somewhere between the call to CL_Font() and CL_FontProvider_Native(); when I specify a non-zero weight, I end up with italic instead. I verified it wasn't fontconfig; I'm not yet set up to trace through all the calls to find out where the mismatch is occurring.

--- Kevin

[rombust]

Many thanks.

I am currently in the process of fixing the Linux fonts. (CL_Font_Native has only been around for 4 days :) ).

Selecting fonts on linux has been an issue for a while now. As you can tell, currently we hard code the fonts.

I did not know of the existence of fontconfig , later i'll have a look at it.

[kbluck]

>However, it seems like params are getting offset somewhere;
> when I specify a non-zero weight, I end up with italic instead.

Scratch that. The problem was in my call to CL_Font(). Anyway, bolding and italicizing both work for me.

--- Kevin

[rombust]

Patch applied, many thanks.

I moved the CL_FontConfig code into Display/X11/font_config.cpp - Else is would have conflicted with the Microsoft Win32 platform (that does not have or need fontconfig)

Some tweaks still are required.

1) ClanLib-0.9/Tests/Display/Font1 - This test now looks different from the windows font to the linux font. See attached for the window screengrab, this is the quality and size linux should match.

2) CL_OpenGLGraphicContextProvider::register_font() - This is used to register a local font (For example: ClanLib-0.9/Examples/DiceWar/Resources/accid___.ttf ). Currently, there is no method of using this font on linux. As it is a freetype font, it 'should' be easy to implement.

[kbluck]

I believe I fixed the height difference; having a look at CreateFont() I noticed that it specifies fonts in "device units", usually meaning pixels, rather than the usual logical unit of "points". So I changed to the FC_PIXEL_SIZE parameter for fontconfig and it matched. Then I had to swap the height adjustment for negative sizes, which to CreateFont() means the difference between "character" and "cell" height. Screenshot of my font1 run on Ubuntu attached along with the patch. You may notice the Times font is a bit short; this seems to be a byproduct of the antialiasing, as when that turns off the letters get noticeably taller. It will probably vary between systems depending on the specific fonts selected.

But this brings up a question: given that we're trying to do cross-platform native fonts here, should we be specifying fonts in Win32 CreateFont()-specific terms? For example, weight is currently 0 to 1000; should we instead just make a few general enums for light, normal, and bold weights? I think that's as much variation as you'll get out of common fonts anyway. And the negative size thing, which I think is pretty obscure. I'm guessing most game programmers (as opposed to typographers) will be concerned with character height, so should we just make that the assumption and forget the negative bit switch between cell and character?

--- Kevin

[Magnus Norddahl]

The negative font size should be fixed, yes.

After I looked through the CSS standard and its way of dealing with fonts, I concluded that people are normally used to specifying the size of a font excluding the internal leading. The font height specified to CL_Font should therefore always map to a negative height for CreateFont.

Fixing this should be fairly trivial, it just requires that Createfont is always fed a negative height, and that all our current CSS files for the GUI themes are updated to use positive font sizes.

The way I see it, the only catch about specifying a height without internal leading is that you risk having your text clipped in some very theoretical circumstances (basically only when you try to use the biggest font possible for an already decided height). I cannot even think of a situation where I would want to do that, so there is no real point in allowing the height to be specified like Windows defaults to.

[rombust]

Patch Applied. Many Thanks

(See http://www.rtsoft.com/forums/showthread.php?t=2291 <-- contains good info :) )

[kbluck]

So, I was thinking about the CL_Font constructor. I think it's a little bothersome to have obscure traits like escapement and orientation so high in the font list. But simply moving those params will break existing code, often without actually breaking build. So, I figure, if its worth breaking a little you might as well break it a lot, to ensure anybody affected will definitely notice the change.

I was thinking that the various style params could be consolidated into a single bitfield parameter, with well-known flag defines that can be ORed together as desired. You could consolidate weight, italic, underline, strikeout, and fixedpitch into that one parameter for sure.

You might also be able to include average width if you wanted to use something like condensed/expanded, etc instead of a specific numeric value. That would be more useful for general font-file selection; if it's important to coerce the m-width to a specific pixel value, that could be an additional optional parameter. I think most people would be content with the generic case, though.

So, your new CL_Font constructor sig would be:



CL_Font(
CL_GraphicContext gc,
const CL_StringRef & typeface_name = cl_text(""),
int pixel_height = 0,
int style_flags = 0,
float average_width = 0.0,
float escapement = 0.0,
float orientation = 0.0);
There might also be a style flag that tells the function to treat height as points instead of pixels. That might also be the way to enable cell height if that's really desirable.

--- Kevin

[Magnus Norddahl]

Actually point sizes are not in cell heights (the MSDN example for CreateFont where they convert from points to device units, they end up using a negative size passed on to CreateFont).

As for the parameters for the CL_Font constructor, I think you are right that most people would not really be interested in most of those values. I believe that games in particular would probably only care about the name, height, style (normal, bold, italic, etc), and in some advanced situations maybe also orientation and escapement.

My suggestion would be to follow the same system as we use for CL_DisplayWindow and CL_DisplayWindowDescription. That is, we have a simple constructor for the common situations and then the description class for more advanced needs. Personally I would probably let simple constructor be something like: CL_Font(gc, typename, pixel_height, style_flags).

[rombust]

So, I was thinking about the CL_Font constructor. I think it's a little bothersome to have obscure traits like escapement and orientation so high in the font list.
--- Kevin

I have implemented CL_FontDescription.

This is coded in the same style as CL_DisplayWindowDescription

So in theory, you can now create CL_FontDescription_Freetype etc, if required.