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

[Dennis-Busch@xxxxxxxxxx]

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)

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).



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)


Dennis Busch
d_busch@xxxxxxxxxx

On 4 Jul 2012 at 13:12, Matthew Leverton wrote:
> On Wed, Jul 4, 2012 at 5:32 AM,  <Dennis-Busch@xxxxxxxxxx> wrote:
> > ( [PATCH for 5.1] and screenshot are attached )
> >
> > Implemented "al_create_builtin_font(unsigned int scale, bool
> > use_tar)" into the font addon.
> >
> I think there should be a built-in font, although we need to consider
> how it should fit in with the library.
> 
> It seems like scaling a bitmap font could be its own thing, although
> I'm not sure how well it fits with the current internals:
> 
> font = al_scale_font(ALLEGRO_FONT *font,
>    unsigned int scale,
>    enum ALLEGRO_FONT_SCALE_ALGORITHM)
> 
> And perhaps scale could even be a float. (Of course if you are loading
> a TTF font, it doesn't make sense to use this.)
> 
> Secondly, we may consider a built-in font in conjunction with a system
> loading function:
> 
> al_load_system_font("Arial", 8);
> 
> Not sure what options would be needed for such a function, but the
> Allegro font could serve as a fallback if the call failed or if TTF
> wasn't available, etc.
> 
> --
> Matthew Leverton
> 
> ----------------------------------------------------------------------
> -------- Live Security Virtual Conference Exclusive live event will
> cover all the ways today's security and threat landscape has changed
> and how IT managers can respond. Discussions will include endpoint
> security, mobile security and the latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers