Re: gEDA-user: gschem text line spacing in postscript

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Tue, 2010-02-23 at 22:01 +0000, Peter Clifton wrote:
> Hmm... this will all be fixed when I get my backside into gear and
> finish up the cairo printing support... until then, I'm not sure..
> 
> It might be something we can fix in the existing printing code, but it
> could also just be a failing of the new cairo text rendering to match up
> with the old printing code. I attempted to match on-screen rendering
> before / after cairo, but never cross-checked how the printing output
> used to match up.

Yep.. the printed output uses a completely different way of calculating
the line height. (Cairo + pango just do it for us in the renderer).

There is some magic going on which is specific only to printing:

libgeda/include/libgeda/defines.h:#define LINE_SPACING    2.0

libgeda/src/o_text_basic.c

static int o_text_height(const char *string, int size) 

which returns:
  26*size/2*(1+LINE_SPACING*(line_count-1))

The printing code offsets by (char_height*LINE_SPACING)

Where char_height is o_text_height("a", o_current->text->size);
IE, 13 * o_current->text->size

A better conversion to mils is probably 1000 (mils/inch) / 72 (pt/inch)
= 13.89 mils/pt.

BUT.. this should also be using the gEDA font size -> points conversion.
The 13 vs 13.89 discrepency is already incorporated in the 1.3 factor
shipped by default.

The short answer.. might be to change the 26*size/2 * ... to be "13.89 *
(float)size * (float)(line_count - 1)

And get rid of "LINE_SPACING" all together.


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user