|
From: | Jeff Finger |
Subject: | [ft] FT_Outline_Get_Bitmap() in 2.3.5 |
Date: | Sun, 9 Mar 2008 16:45:01 +0200 |
1.
My reading of the documentation and
code is that when FT_Outline_Get_Bitmap is called, the
bitmap passed in should already have all its fields set, including bitmap->pixel_mode and bitmap->num_grays. Correct? The renderer can then know the format of the
bitmap into which it is OR-ing the outline’s rendering. 2. I am dealing with client code that calls FT_Outline_Get_Bitmap, but does
not set num_grays when pixel_mode==FT_PIXEL_MODE_GRAY. I think
this is a bug in the client code, but it works ok because gray_raster_render assumes
that bitmap->num_grays==256, as does
the client software. Specifically, ftgrays.c creates 256 gray values unless you
provide a replacement callback for gray_render_span via the FT_RASTER_FLAG_DIRECT bit in params->flags. Am I
missing something obvious in what I am saying? (Note that the 256 value is
hardcoded into ft_smooth_render_generic, but this is bypassed when
calling via FT_Outline_Get_Bitmap.) If my analysis is correct, then
if you pass into FT_Outline_Get_Bitmap() a bitmap->num_grays that is
other than 256, you’ll still get values from [0..255] unless you provide
your own render_span replacement. My tests show this to be true, and if so, I believe it
should be documented. But, again, maybe I am missing something. 3. There is a typo, I believe, at line 132 (both CVS and Release
2.3.5) of include/ftimage.h in the documentation. Instead of 'num_bytes', it
should say 'num_grays'. /* FT_PIXEL_MODE_GRAY
::
*/ /* An 8-bit bitmap, generally
used to represent anti-aliased glyph */ /* images. Each pixel
is stored in one byte. Note that the number */ /* of value `gray' levels is
stored in the `num_bytes' field of */ /* the @FT_Bitmap structure
(it generally is
256).
*/
/* */ Many thanks, Jeff Finger No virus found in this outgoing message. |
[Prev in Thread] | Current Thread | [Next in Thread] |