freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freetype] The kind of anti-aliased colored fonts I'm talking about


From: David Turner
Subject: Re: [Freetype] The kind of anti-aliased colored fonts I'm talking about...
Date: Tue, 11 Jun 2002 01:54:14 +0200

Hello Paul,

"Pedriana, Paul" a écrit :
> 
> I posted last month lamenting the imability of font systems to support
> colored alpha blended fonts. I also mentioned that in the game industry,
> all the best quality games implement this. I thought I'd post a typical
> example taken from Blizzard's Warcraft series of games. Here is a
> typical screenshot of what I'm talking about:
>       http://www.blizzard.com/war3/screenshots/s14-large.shtml
> 
> Click on the image to see it at 100% scale. Click on the "next screenshot"
> link to see other screenshots. Here is another example:
>       http://www.blizzard.com/diablo2exp/screenshots/800x/ss06b.shtml
> 
> This is the kind of text display we want and while standard TrueType and
> PostScript text is OK and convenient, they are not as professional looking
> as anti-aliased colored ("ARGB") text. I think that perhaps they lack the
> support for ARGB because they were designed at a time when alpha was
> considered somewhat exotic for realtime desktop computing.
> 
> The Freetype documentation for FT_Bitmap suggests that in fact colored
> bitmaps are a possibility if a driver was written for such a thing. I
> imagine
> that this is the route I want to take. It seems that the num_grays field
> would be meaningless for such a thing and that the pixel_mode field
> would be set to some value defining the ARGB format of the bitmap.
> As many people are aware, there are many common ARGB formats, such
> as ARGB_8888, ARGB_1555, RGBA_5551, and ARGB_4444. The pixel
> mode field, however, says how many bits there are, and says nothing about
> what the format of the bits is.
>

The problem is that we don't want to put pixel depth management code within
FreeType, since it has little to do with what a font engine should do. However,
you can most certainly achieve what you need by performing something like
the following:

  - write a custom "colored" bitmap font driver for FreeType that
    is capable of reading your font files.

  - use a custom FT_Glyph_Format tag for your own use. That way,
    FreeType will not think that it can manage the resulting bitmaps.

    You will be however capable of using the "face->glyph->bitmap"
    field to store the bitmap descriptor after a FT_Load_Glyph
    (just ensure that your driver sets face->glyph->format to your
     custom tag, and not to "ft_glyph_format_bitmap")

    you'll then be able to use the "pixel_mode" field of
    "face->glyph->bitmap" to your liking since it will never be
    accessed directly by FreeType. Just use whatever enumeration
    values you'd like to designate the pixel depths you use in
    your projects.

  - if you want to use the FT_Glyph functions, you'll need to
    write a dummy "renderer" module that handles your tagged
    bitmaps (and performs bbox computation and a few other
    stupid thing). However, I don't think it'd be a very
    interesting thing to do.

  - on the other hand, you could probably write a custom SBit
    cache class for the FT2 cache sub-system that would handle
    your format.

  - Generally speaking, you're looking for a very custom solution,
    since I don't think that standard font files are capable of
    dealing with ARGB bitmaps anyway. Writing a custom font driver
    seems inevitable unless you want to drop FreeType.

Finally, if you're designing a custom font format, try to model
it around TrueType and the SFNT storage scheme, since you'll be
able to re-use certain parts of the engine to parse these.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]