[Top][All Lists]
[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)