Sorry for the late reply.
> Hello guys, I am looking at the documentation for FT_Bitmap and the
> information for the pitch data-member says the following: "the pitch
> is positive when the bitmap has a ‘down’ flow, and negative when it
> has an ‘up’ flow". I searched in the documentation, but there is no
> information on how to control this, if possible. I imagine that,
> practically speaking, the pixel data/image will always have a ‘down’
> flow.
If you select the wrong direction, the image will be vertically
mirrored...
> The FT_Bitmap documentation also says: "Note that ‘padding’ means
> the alignment of a bitmap to a byte border, and FreeType functions
> normally align to the smallest possible integer value". Does that
> mean (hopefully) that, practically speaking, an FT_Bitmap generated
> with FT_Render_Glyph (with FT_RENDER_MODE_NORMAL or
> FT_RENDER_MODE_SDF) will almost never have padding? It seems that,
> if I have doubts and want to make sure in the code that padding is
> never there, I can call FT_Bitmap_Convert to remove the padding, but
> I am not sure about it: does using FT_Bitmap_Convert with a value of
> 1 for the "alignment" parameter means "remove the padding from the
> Bitmap"?
If you access a bitmap byte-wise, the padding is zero. However, if
your graphics framework accesses bitmaps with 32bit entities to speed
up things, padding up to three bytes can happen; that is, the pitch is
a multiple of four.
> Now that I think about it (about the flow of the pixel data in the
> FT_Bitmap), the documentation says: "In all cases, the pitch is an
> offset to add to a bitmap pointer in order to go down one row",
> which means that, for example, if I copy the pixel data into a
> std::vector<uint8_t> and I just go row by row, one at a time, and
> incrementing (+=) the pixel data pointer each time by the pitch, at
> the end, the FT_Bitmap's flow doesn't matter. However, I still want
> to express my question about the FT_Bitmap's flow, so I decided to
> keep the first paragraph of this email.
The bitmap flow does matter – if the pitch is negative, you have to
start at the end of the bitmap buffer, since '+=' essentially
decrements the pointer.
> Also, just in case this matters, I don't do fancy things with my
> program, its scope is to be a simple font generator:
> FT_Get_First_Char, FT_Get_Next_Char, FT_Load_Glyph, FT_Load_Char,
> and FT_Render_Glyph are pretty much all I use (apart from, for
> example, FT_Select_Charmap to explicitly set/request a Unicode
> charmap).
If you need examples for coding, look at the FreeType demo programs
like `ftview`.
Werner
