Just posting this here, so I can link to this thread and the attachment in the message which I'll write to the developer mailing-list in a moment.

Briefly, this is about a request to include an embedded font within the "allegro_font" addon, so that it would be possible for example to display some quick debugging info without having to load an external font file.

I already wrote the function and adapted the font data from Allegro4 for that (see attached zip, which includes the code to create the font at runtime and a modified ex_bitmap.c to demonstrate usage).

edit
attached a new version with minor changes (fixed potentially problematic call to allegros font grabbing function (I wasn't sure whether it was safe to pass NULL for any pointer parameter and if these parameters are sanity checked (!=NULL) inside the function but now that should never happen.) and fixed a comment)

I think it would be good to have this as a standard add-on in 5.2. The function name is terrible though... Something like al_get_generic_font() is easier to remember. Perhaps it could take a scaling parameter.

Also, it might be beneficial to have this in the same add-on:

al_load_system_font( int family, int size, int flags );

// these could be hard-coded to known OS fonts
ALLEGRO_FONT_MONOSPACE (e.g., Courier)
ALLEGRO_FONT_SANS_SERIF (e.g., Arial)
ALLEGRO_FONT_SERIF (e.g., Times New Roman)

// user fonts ... some intersection of commonly defined fonts
ALLEGRO_FONT_DESKTOP
ALLEGRO_FONT_WINDOW_TITLE

Alternatively:

al_load_system_font( const char *name, int size, int flags );

"Verdana, Arial, sans-serif"

I renamed the function to "al_create_default_font" and attached the new version (plus minor fixes) to the first post. I would keep the "create" in the function name as a hint that the user is responsible for cleaning it up in the end via "al_destroy_font".

Loading system fonts would be sweet indeed. For the font family parameter there could maybe even be a parameter like ALLEGRO_FONT_SYSTEM_DEFAULT which would try to load whichever font is usually 100% certainly available on the executing platform (and maybe fall back to a built-in font if that fails).

I've figured out how to do the thing on OS X: get Library locations (usually ~/Library with fall back to /Library, but there are cocoa functions for getting this that one should use instead of hardcoding) and then look for Fonts. The non-trivial part is figuring out the filename you want, which is typically "Fontname Bold Italic.ttf" or "FontnameBold.ttf", but could be anything really. I guess it's possible to try those first, then look at the font descriptions in each font file until the desired font is found.

Anyway, this is mainly a note to myself for how to implement this once an API is decided on and there is nothing left to do on 5.0.

The alternative would be to not use Freetype at all and use OS functions to render glyphs instead (without ever knowing the font path). This would be more work to implement though.

Sure. If I want an NSFont. But I don't, I want an ALLEGRO_FONT, which means I want to know a path to a filename.
It has a proper API for drawing text too, and we're also duplicating that.

Wouldn't work with bitmap fonts and means a substantial redisign of the font addon.
Not something we should be doing right now.

Yeah I misworded that. But it doesn't really matter, OSs like OSX and Windows really couldn't care less about apps that don't use the native toolkits.

Sure, but actually trying to search for a specific font family or other things just won't work. At best you'll be able to do is look at the file name, and thats probably not enough, unless we want to hard code font filenames. But thats not guaranteed to work at all.

Might be an idea to see if fontconfig works on osx and windows. It could be very useful.

It's available in DarwinPorts, which gives its description as "An XML-based font configuration API for X Windows", so I'm guessing no native version.

This (from the port file)

suggests it's almost (but not quite) looking in the same locations I posted earlier (the function we use for the native file location API on OS X will actually return an array of locations, so if you asked for Library locations it would return all of Library, Networl/Library, System/Library, $HOME/Library; it's important to look in all those locations, I guess).
But there has to be a way (using FreeType?) to get things like font family and the like from the font file? That way, we could do a good "first guess" for common types, then fall back to doing a brute-force search if it fails.
Font loading should not be time-critical code anyway.

Could do, I suppose. On the other hand, I don't think we need to do it if the user asks for a specific font type and we can do an educated guess first.

OS X lists "Arial.ttf", "Arial Bold.ttf", "Arial Italic.ttf" and "Arial Bold Italic.ttf" as "Family Arial" with "Typeface Regular, Bold, Italic, Bold Italic", but it lists "Arial Narrow.ttf", "Arial Narrow Bold.ttf" etc. as "Family Arial Narrow" with "Typeface Regular, Bold, Italic, Bold Italic".
Actually, I think the only recognised typefaces are "regular", "bold" and "italic" (and the combination "bold italic"). Anything else is lumped into the font family.

Since this would sit on top of the TTF addon, which uses FreeType on all platforms, that shouldn't be a problem. Probably a good thing actually.

So as the function searches for a font:

• it searches its memory cache first

  
  

• when that fails it searches the paths, but not bothering to open any files that already have an entry in the cache

  
  

• every file that it finds that is not what was wanted still has its information remembered in case it is useful for later

  
  

• It will keep searching for the font until it has run out of locations (meaning an exhaustive search was performed and still failed, by this time all system fonts would be enumerated).

  
  

• It flock()s & writes any new font cache entries into font cache file in temporary files (%temp% /temp or w/e) on allegro_exit (probably skip if flock fails after 3 seconds in a row or something).

Should programmers should probably be able to specify additional search paths? Ones that would will also override system fonts if clash (i.e ./fonts relative to program executable's assumed path). Might be useful in highly user-customizable, redistributed programs.

Loading /temp/allegro-fonts.cache or w/e, should have a timestamp for each entry, should validate that each entry still exists and has not been modified since, should do this at add-on initialization.

My 2 cents

It would better belong in temp, or data rather than settings.

Would this read in all system fonts?

cache = al_font_info_cache(ALLEGRO_SYSTEM_FONTS);

And what would be the code to get an ALLEGRO_FONT once I have the ALLEGRO_FONT_INFO of the font I want?