Hi.
I've altered the behaviour of the font rendering function of Gimp
to correct what would be a bug from my point of view. Since the
behaviour was put in intentionally and worked as expected, it might
be I altered something that was supposed to work the old way for
some reason I don't see. Here's the problem:
In a perl-fu script I write, I need to be able to place text strings
baseline to baseline, so they all are at the same height position, like
they would be in a book. Depending on the characters used in the
strings, the Gimp alters the y position of the strings, so the baselines
do not match anymore.
The reason for this is that the text render routine crops away empty
regions of the rendered text. If you render "meow", as opposed to
"Meow", there'll be an empty space over the letters. A crop routine
removes that space. The new region is smaller, the text is higher up,
and since the the crop routine doesn't tell how much it cropped away you can
not even correct the position of the text.
Removing the call to the crop routine gives me exactly the behaviour
I need, and the behaviour one would expect. With fonts, after all, the
baseline is what gives the position, not the upper border of the highest
letter.
My point is that every time you need to place more than one string
on the same baseline you have to rely on The Gimp to give you the correct
position. Wether you want to change the font family, size, slant or (as in
my case) want to draw one additional letter in each new frame of an animation,
you have to have a text render function working with baseline positioning.
I can easily patch new versions of Gimp for the behaviour I want
since it's just removing one line, but I think it'd be better to alter
it in the distribution. But that'd require that the new behaviour doesn't
collide with something that was intended and is still valid and that I
don't see. I'm no developer, so I'm asking here. What now? :)
Greetings,
Andy
