Hello Andreas,

I needed the same feature some years ago when I wrote an ASCII plugin
that was able to read and display ASCII files. At that time a change was
made
that the renderer will not crop when the border-parameter was specified
with a negative value. I suppose this feature works up to now.
I dont know what this border parameter is good for. Specifying any value
always cropped me the textbox. But since a lot of scripts are using
gimp-text, changes should be made carefully.

--Peter

Andreas Jaekel wrote:
> 
> 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

-- 
Peter Kirchgessner
WWW:    http://www.kirchgessner.net
e-mail: [EMAIL PROTECTED]

Reply via email to