Re: [AD] monochrome 8x8 builtin font + upscaling algorithm

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sat, 07 Jul 2012 14:32:50 +0200
Dennis-Busch@xxxxxxxxxx wrote:

> 8x8 builtin font:
> I think it could be included as is for the time being. The scaling 
> here is very simple and only applicaple to monochrome 1bit data, the 
> algorithm is very compact and does not take up much space.
> 
> Later, when I (or someone else) gets around to starting the generic 
> scaling algorithms addon, it could be refactored to use that instead 
> so there would not be any duplicate code in the font/scaling addons.
> 
> Keeping that in mind though, maybe the function should be rewritten 
> once more for now to simply return an unscaled ALLEGRO_BITMAP which 
> only contains the 8x8 font characters which users can then pass to 
> al_grab_font_from_bitmap themselves (or apply any of their own 
> scaling before doing so).
> 
> So maybe we might only want something like
>   "al_create_builtin_font_bitmap"
> for now? (returns an ALLEGRO_BITMAP instead of ALLEGRO_FONT)
> (to keep it open and flexible for future extensions and allowing the 
> user to manipulate it any way they like before usage)

I would prefer that.

> 
> The (to be created) generic scaling algorithms addon should then work 
> on ALLEGRO_BITMAPs to allow scaling any bitmaps and not just bitmap 
> fonts.
> 

And it could then also contain a convenience function which calls
al_create_builtin_font_bitmap (maybe _sheet would be a better name?),
applies the scaling and creates the font.

> 
> 
> TTF builtin font:
> I've been playing around with 'fontforge' and the Bitstream Vera 
> fonts, trying to strip and remove all unnecessary information from 
> the font file (as advised by Elias).
> 
> The smallest font file I could produce from that was 17.1KB including 
> the same ranges as the Bitstream Vera font.
> 
> That still sounds like a big chunk of data for embedding.
> 
> Instead of embedding a default TTF font, another option would be to 
> define a list of 'preferred debug font' names for each system and try 
> to load one of these in a generic
>   al_load_default_font(void)
> function (returns null if no such font could be found).


I don't think 17.1KB is anything to worry about. In Allegro 4 a single
RGB_MAP was 32KB and a single COLOR_MAP was 64KB - and that was at a
time where your whole system memory was 640KB. Also the static data for
your 8x8 bitmap font are 20KB. So if you can embed a TTF in 17.1KB
that's outright tiny.

> 
> 
> TTF enumerating/loading available system fonts:
> I think that should be a separate feature/patch independent from the 
> idea of having a builtin/default font.
> 
> The loading function does not even need to return any builtin font on 
> failure, it should simply report failure and then the user code 
> should handle it.
> (Not everyone might want to automatically get some other font in that 
> case.)
> 
> There should probably just be a function which returns a list of 
> filenames (full path, short name without extension) of font files 
> found on the system (in pre-defined locations... it should NOT look 
> everywhere):
>   al_enumerate_system_font_files(void)
> 

There probably should be both. The enumeration function which just
gives you a list of filenames (or directories even). And then a
convenience function on top which always returns a font but tries to
normally return the one asked for or the one closest to it.

Not sure this can work on all platforms, some might not give you a
filename to load the font from but expect you to leave the loading to
the OS (and just give you the fonts themselves). Would have to
investigate though, maybe it would work.