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 - incorrect calculation of line spacing?
Summary: incorrect calculation of line spacing?
Status: RESOLVED FIXED
Alias: None
Product: SDL_ttf
Classification: Unclassified
Component: misc (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-19 05:10 UTC by Sam Lantinga
Modified: 2006-05-01 05:26 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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!