Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incorrect calculation of line spacing? #1

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

incorrect calculation of line spacing? #1

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-19 05:10:45 +0000, Sam Lantinga wrote:

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

On 2006-01-27 11:23:16 +0000, Ryan C. Gordon wrote:

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.

On 2006-05-01 05:26:41 +0000, Sam Lantinga wrote:

This is fixed in subversion, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant