I think this could be an extra addon, something like "allegro_standard_font" or similar. This seems to me to fit nicely with Allegro 5's modular design.

Apart from that technical detail, this seems like a good idea. Not sold on the A4 font though; it's a bit small at today's resolutions. Would it be possible to embed a TTF font?

I dislike the name, but I don't see why it cannot be part of the regular font add-on. I don't really see a reason for an add-on that is full of embedded fonts. IMO, you either want a quick and dirty one for debugging or you want the full control of loading external TTFs.

I bet I'm not the only one using the a4_font.tga that comes with the Allegro 5 examples for my games. On my monitor it's a good size both for debug info printing and other text. It does the job, but a better looking font wouldn't hurt either.

An easily available font for use early in the project, for debugging, or just when you can't be bothered to find something else would be handy.

Freefont itself doesn't know.
You can check here the locations for a handful of OSes (OSX, Beos, Haiku,..)
http://code.google.com/p/grafx2/source/browse/trunk/src/text.c#292

Done. See updated main post (includes screenshot). I hope I didn't miss any important style convention from the A4 hackers guide.

With the link Audric provided I'll look into starting with a new function for the TTF Addon soon(ish) but that will be a separate patch.

I did not find a scale or size parameter in any of the text drawing routines and I was not aware of al_scale_transform when I wrote it.

I think it does not hurt to have it though now that it's already there.

The documentation could include a hint that scaling can be achieved by other means and that using the scaling parameter in the creation routine will cause the font to use up more texture memory as you pointed out in IRC.

Using a combination of both al_scale_transform and a different scale on creation time may yield some interesting results though.

Depending on how interpolation works, drawing a 2x or higher scaled(at creation time) version at less than 0.5 size (using al_scale_transform) may lead to cleaner or dirtier rendering output.

EDIT:
Maybe I should attempt to implement something like http://en.wikipedia.org/wiki/Hqx for the scaling. Thoughts?

I started thinking about a simple up-scaling smoothing algorithm for this special monochrome (1 bit) case for scaling the available font data bits into something less blocky.

It won't be able to generate nice curves, nor would it be able to get any non-multiple of 45 degrees lines corrected or even nicely extrapolated but I think the result would be good enough to make looking at it more tolerable than looking at blocky fat pixels.

The basic idea is to test around a given target (fat)pixel for intersecting "lines" and then slapping one or more of 8 different (scaled) triangles into the (fat)pixel in a lower pixel resolution.

I fixed my thoughts in the following (not yet complete) diagram:
{"name":"606204","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/9\/29d5be62ba7307f101afc39d1af302af.png","w":537,"h":618,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/9\/29d5be62ba7307f101afc39d1af302af"}

I'd basically have four different tests in four different orientations each. Each test would have to check at most 6 bits. Some tests must have precedence over others. Each test must specify which of the eight triangles to render into the gap to iron it out. There'd be a few special test cases as well.

----
append (July 1st 2012):
Thought about it some more and I will implement some up-scaling de-blockification according to the following draft:
{"name":"606224","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/a\/9a6e2f16de2a8d54a94ba9ee60e82213.png","w":256,"h":256,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/a\/9a6e2f16de2a8d54a94ba9ee60e82213"}

append 2 (additional notes(view with monospaced font) to the above image and the algorithm)

+------------------------------------------+
|Monochrome Font Upscaling Algo v.1.0 draft|
|"Tri-add-rem" by Dennis-Busch@gmx.net     |
|July 1st 2012                             |
+------------------------------------------+

(see also "Tri-add-rem-draft10b.png")

Short description:
------------------
Examine bits around source pixel and reshape scaled target "pixel"(square) by adding or removing one or more of four triangles to/from the 

target square.

Random thought: Could easily be adapted for achieving differently styled result by using other shapes than triangles, e.g. cirlce 

sections.

triangles 0 to 3:
-----------------
(the sides on the right angle are supposed to be even in length and their length is half the target square side length)
+--+ +--+ +       +
| /   \ | |\     /|
|/     \| | \   / |
+       + +--+ +--+
 t0   t1   t2   t3

Bits around target square/source pixel:
---------------------------------------
bit 0, bit 1, bit 2
bit 3, ts/sp, bit 4
bit 5, bit 6, bit 7
(ts = target square, sp = source pixel)


A test case(rule) includes the following information:
-----------------------------------------------------
  a.) an "apply only on scale factor 3 or more" bit (to prevent erasing/adding 
      full squares on scaling factor 2 for some otherwise generic rules) 

  b.) a "stop bit" to specify that no other rule should be tested if this rule
      applies (rule tests must be sorted so that rules with higher precedence will be
      tested first)

  c.) the bit pattern (set, un-set, don't care) which the bits around the source pixel
      must represent in order to apply the triangle operations to the target square
      (need two bits per bit in the pattern to represent the "don't care" setting)

  d.) four triangle bits specifying which triangles to apply(add/remove)
      (if sp is set they will be removed otherwise they will be added)

So there will be 22 bits per rule, so each rule needs 3 bytes to be stored:
a,b,d can be stored together in one byte and c can be stored in two bytes
00ddddba | cccccccc (set/unset bits) | cccccccc (don't care bits)
       1          1                           1 (least significant bit)
  0123     01234567                    01234567 (triangle numbers, surrounding bit numbers)

rules for 'set' source pixel (only remove triangles):
-----------------------------------------------------
example for the first non-exclusive rule in the diagram on the image file
00101000 | 00001000 | 00000000 (left 'line' ending)
  0123ba | 01234567 | 01234567

example for the first exclusive rule in the image file
00111111 | 00000000 | 00000000 (single square surrounded by unset bits)
  0123ba | 01234567 | 01234567

todo: add rules

rules for 'unset' source pixel (only add triangles):
----------------------------------------------------
example for the second exclusive rule in the image file
00111111 | 01011010 | 10100101 (empty square surrounded by set/don't care bits)
  0123ba | 01234567 | 01234567

todo: add rules

Have you ever wasted two days implementing a complicated algorithm until you realized you can achieve the same effect with a MUCH SIMPLER method? No? Well, I just did that.

As I was adding more and more of those rules I realized I can base all of that on much simpler rules:
I only need to determine for each triangle whether to draw it or remove it.
This can be done by examining the three pixels neighboring the triangle:

If the center pixel is set and the three neighbor pixels of a triangle are empty, remove that triangle.

If the center pixel is not set and the orthogonal neighbor pixels of a triangle are filled, add that triangle.

In both cases, if there are at least two triangles being added or removed, make them slightly smaller.

Simple.

And I already had this very complicated system (complete with lookup table and rule definitions in place... :X ).

Overly complex code^[1] and image below are included just for laughs: XD
(I will rewrite that with the simple rules from above.)
{"name":"606234","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/c\/8c15d6b58d7710819af79d811e0969a0.png","w":256,"h":256,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/c\/8c15d6b58d7710819af79d811e0969a0"}

--- append ---
Updated main post with new simple up-scaling implementation and patch.