We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 51

Summary: incorrect calculation of line spacing?
Product: SDL_ttf Reporter: Sam Lantinga <slouken>
Component: miscAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: andras
Version: unspecified   
Hardware: All   
OS: All   

Description Sam Lantinga 2006-01-19 05:10:45 UTC
Current SDL_ttf (http://www.libsdl.org/cgi/cvsweb.cgi/SDL_ttf2/) seems
to calculate bounding boxes based on the maximum and minimum values that
appear in the font, as opposed to the used glyphs only.  This means that
fonts containing some of the Unicode Block Elements will generally cause
SDL_ttf to use very large line spacing, even if the Block Elements are
not actually being used in the application.
    http://www.unicode.org/charts/PDF/U2580.pdf

>From Stepan Roh, project manager for the DejaVu font family:
> In version 1.14 Box Elements were added
> (created by David Lawrence Ramsey). Those glyphs have bigger descent than
> other glyphs which cause the change of yMin value in TTF 'head' table from
> -492 to -1034 (note that this value comes from Sans Mono and their Box
> Drawing glyphs). This may explain your observations, however (I believe)
> correct rasterizer should either compute bounding boxes of used glyphs
> only (not of the whole font) or use typographic descents (either from
> 'hhea' table or from 'OS/2' table). I have DejaVuSans 1.14 installed in
> KDE as a system font and it clearly uses one of those approaches.
>
> As I look through SDL_ttf sources on a location you provided I see
> (function TTF_OpenFontIndexRW):
>
>            font->ascent  = FT_CEIL(FT_MulFix(face->bbox.yMax, scale));
>            font->descent = FT_CEIL(FT_MulFix(face->bbox.yMin, scale));
>
> ... which looks like what I was talking about. I think you can try to
> change it to:
>
>            font->ascent  = FT_CEIL(FT_MulFix(face->ascender, scale));
>            font->descent = FT_CEIL(FT_MulFix(face->descender, scale));

I have tested this suggested change with DejaVuSans 2.1 and after
this tweak, SDL_ttf now renders this font correctly in our application
(Battle for Wesnoth, http://www.wesnoth.org/).  Please consider this
change for SDL_ttf.

(Stepan also had some other comments, see
    http://sourceforge.net/mailarchive/message.php?msg_id=13151599
for his full message.  The change above is the most generally relevant.)

-- Andras Salamon                   andras@dns.net
Comment 1 Ryan C. Gordon 2006-01-27 11:23:16 UTC
Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

Comment 2 Sam Lantinga 2006-05-01 05:26:41 UTC
This is fixed in subversion, thanks!