[PATCH 4/4] print.c: Reduce vertical spacing between tank entries

[Carl Worth]

"Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
> It seems that
> cairo_translate(cr, 0, logic_ext.height / (2 * (double) PANGO_SCALE));
> with the multiplier (2 *) leaves no space between the tanks when testing
> on Win32. On the other hand on Ubuntu there seems to be some extra space
> bellow the four entries. Some sort of cairo inconsistency perhaps or we
> may be doing something silly.
>
> Lets change the multiplier to 1.5 to leave more vertical space between said

Tweaking the multiplier is just trying to fix the result without
understanding the problem.

>  		pango_layout_get_extents(layout, NULL, &logic_ext);
> -		cairo_translate (cr, 0, logic_ext.height / (2*(double) PANGO_SCALE));
> +		cairo_translate (cr, 0, logic_ext.height / (1.5 *
> (double) PANGO_SCALE));

The only reliable way to know how large your text is is to measure
it. And that's what pango_layout_get_extents does.

So translating down by the logical extents height (divided by that
annoying PANGO_SCALE) shifts things down to the correct position for
drawing a subsequent line of text, (where "correct" line spacing is
determined by the designer of the font being used here).

Multiplying by 2 (or 1.5 or anything else) just puts your text into some
random location.

I'm not sure what the bug is that is causing you to get inconsistent
results.

But you've really got only two sane options for layout of text:

  1. Use the natural line spacing of the font, allow boxes and
     containers to grow to accommodate the text, (or else take advantage
     of pango's features to ellipsize text that is too long).

OR:

  2. Allocate your box first, and let its size determine the line
     spacing. In this case, you can choose a font size to force things
     to fit, (and again, you'll need to measure the text you plan to
     draw with something like pango_layout_get_extents to ensure you got
     a size you expected). This kind of approach can require some logic
     to search for a suitable font size.

The code above (both old and new versions) isn't doing either of these
things. So the true bug really should be found and fixed.

-Carl

-- 
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130211/0800da4c/attachment-0001.pgp>