Re: [ft] Rendering problem

[Patrick Baggett]

On Fri, Sep 23, 2011 at 3:56 PM, Farmer, Anthony <address@hidden> wrote:

Thanks, Patrick.

 

Unfortunately when I specify an origin in FT_Glyph_To_Bitmap(),nothing happens.  I’ve even tried setting it to wacky values, but no effect.  So there’s no way to determine the Y offset of the Baseline in an FT_BitmapGlyph?

What your asking seems to be more of "what is the maximum height of a character"? FT_Set_Char_Size() does that. Based on the point size (26.6 notation) and the DPI you can calculate it. A point is 1/72 of an inch if I recall, and DPI is the number of dots (pixels in this case) per inch, so:

X points * ( 1 point / 72 inches) * ( DPI dots / 1 inch ) = X * DPI / 72 dots. Even the units work out, heh.

FT_Set_Pixel_Sizes() works too, if you're specifying in pixels. I personally find that to be more useful for things like games where people don't care about the precise point size of the font.

 

 

My sequence of calls basically looks like this:

FT_Set_Char_Size(face, 48*64, 48*64, FONT_DPI, FONT_DPI);

FT_Load_Glyph(face, charIndex, FT_LOAD_DEFAULT);

FT_Get_Glyph(face->glyph, &glyph);

FT_Vector origin = {0, 0};

FT_Glyph_To_Bitmap(&glyph, ft_render_mode_normal, &origin, 1);

 

I do this for all the glyphs I care about then copy the bitmap buffer to my own buffer, which then gets stuffed into an OpenGL texture, as shown in the attachments sent prior.

 

The origin "translates bitmap before rendering". I'm not so sure that is what you need. I'm actually not positive what effects it would have, though I do know it isn't necessary to solve this problem.

 

I’m trying to use the bounding box of each glyph at the moment, but in order to do so I must INFER where the baseline is.  If there were some way to just KNOW the Y offset of the baseline, I could add the decender value then add the height and I’d have the correct row offset in my “destination” buffer. 

If you reason about it, for any K point font, there is a maximum Y value for where to begin that's y(K). It just so happens that y(K) is actually y(K, DPI) = K * DPI / 72.0. Here is my first thought about the algorithm to place text

Let M be the maximum height of any glyph when rendered. Use one of the above methods to define M [1:point size/dpi, 2: explicitly via Set_Pixel_Sizes].

penX <- 0

penY <- M

for each glyph that needs to be rendered

  Render the glyph to a bitmap

  if penX + bitmap.width  > texture.width, then

      penX <- 0

      penY <- penY + M

  end if

  CopyRect(penX, penY,   //origin inside of texture

               0, 0, //origin inside bitmap

               bitmap.width, bitmap.height //width/height of bitmap

               )

end for

 

 

Of course if “origin” did what I expected, it would automatically line everything up.  But it seems to do nothing at all.

 

Thanks for your help,

Anthony

 

 

 

 

 

From: Patrick Baggett [mailto:address@hidden]
Sent: Friday, September 23, 2011 12:58 PM
To: Farmer, Anthony
Cc: address@hidden
Subject: Re: [ft] Rendering problem

 

The baseline is a point you give. The coordinates for the glyph are relative to an origin. So the punctuation should be just a small bit off from the baseline. If you set your baseline to be (0,0), then it bitmap space, you're in the upper left. Increasing Y moves you down, but in font terms it moves you up (Cartesian coords). Maybe the difference there has something to do with it. The baseline for your font really should be lower, say for 16px font, at (x,15).

 

In other words, if you render a 16pt glyph at (0,0), move over say, 12 pixels to (12,0), render another 16pt glyph, and so on, you get this:

 

(0,0)                  +X

0----------

| G1| G2|
|   |---+

|---+

|

+Y

 

 

You need to make sure that you actually copy the rendered glyphs to some position on the bitmap so the bottom of the rect of th glyph is always on teh baseline, and the baseline should always start at FONT_PIXELS_HEIGHT below 0, i.e. if your largest font glyph can be 16 pixels tall, you need to use 15 as a baseline Y so that [0,15] can be filled.

 

Patrick

 

 

http://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html

On Fri, Sep 23, 2011 at 12:12 PM, Farmer, Anthony <address@hidden> wrote:

Hello.

 

I’m trying to load a font into a bitmap, then into an OpenGL texture for rendering, and have encountered a problem with the font baseline that I’m unable to resolve via online documentation or Google search.  Attached is a small bitmap showing what happens, which hopefully obviates what I’m doing wrong and how it can be corrected.

 

Briefly, I convert all the glyphs to bitmap glyphs then extract them sequentially into an OpenGL texture.  Later I use the X-offset into that texture for rendering text.  Unfortunately all the punctuation is being placed at the TOP of the GL texture, as if the baseline were there instead of along the bottom.  I don’t believe that’s the case, but that’s the behavior.

 

If there were some way I could extract the vertical location of the face’s BASELINE, I could adjust everything accordingly as glyphs are extracted.  But I see no way to get that baseline value.

 

Or perhaps there’s another approach altogether that I should be taking?

 

Thanks,

Anthony Farmer

This e-mail is confidential. If you are not named above as an addressee or are not the intended recipient of this e-mail, please notify the sender and immediately delete it.
E-mails are susceptible to data corruption, interception, falsification, delay, unauthorised amendment and viruses. You should therefore carry out such virus and other checks as you consider appropriate. Cantor Gaming does not accept liability for any such events or any consequences thereof in respect of e-mails sent or received. Copyright and any other intellectual property rights in its contents are the sole property of Cantor Gaming.
The contents of e-mails may be monitored for security purposes. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Cantor Gaming.
This email was sent to you by Cantor Gaming. Cantor Gaming is the trading name of Cantor G&W Nevada L.P., a Nevada limited partnership with offices located at 135 East 57th Street, New York, New York 10022, and Cantor G&W International L.P., a limited partnership registered in England (registered number LP010479) with registered office One Churchill Place, Canary Wharf, London E14 5RD.

_______________________________________________
Freetype mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype

 

This e-mail is confidential. If you are not named above as an addressee or are not the intended recipient of this e-mail, please notify the sender and immediately delete it.
E-mails are susceptible to data corruption, interception, falsification, delay, unauthorised amendment and viruses. You should therefore carry out such virus and other checks as you consider appropriate. Cantor Gaming does not accept liability for any such events or any consequences thereof in respect of e-mails sent or received. Copyright and any other intellectual property rights in its contents are the sole property of Cantor Gaming.
The contents of e-mails may be monitored for security purposes. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Cantor Gaming.
This email was sent to you by Cantor Gaming. Cantor Gaming is the trading name of Cantor G&W Nevada L.P., a Nevada limited partnership with offices located at 135 East 57th Street, New York, New York 10022, and Cantor G&W International L.P., a limited partnership registered in England (registered number LP010479) with registered office One Churchill Place, Canary Wharf, London E14 5RD.