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

[Trent Gamblin <trent@xxxxxxxxxx>]

And now trying for a third time, from different email address.

On 2012-07-08, at 3:47 PM, Trent Gamblin wrote:

> I tried replying to this a couple days ago, but they seem to have not made it.
> 
> 
> On 2012-07-07, at 6:32 AM, 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 agree with Elias on this. I think creating the full bitmap is all that's needed.
> 
>> The (to be created) generic scaling algorithms addon should then work 
>> on ALLEGRO_BITMAPs to allow scaling any bitmaps and not just bitmap 
>> fonts.
>> 
>> 
>> 
>> 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 we should have either of these. If someone wants a built-in font, the only use case is for quick debugging purposes, so that's what the above one is. If you want a ttf, ship the one you want with the game yourself. Definitely against this.
> 
>> 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)
> 
> For this I don't know much about it, but I'm all for enumerating system fonts.
> 
> Trent
>