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: peter@xxxxxxxxxxxxxxxx
