Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Gimp Traffic #8 For 7 Jan 2000

By Alex Harford

Table Of Contents

Introduction

Welcome back to Kernel Cousin Gimp. Things were quiet this week, perhaps everyone is recovering from their New Year's partying.

Mailing List Stats For This Week

We looked at 25 posts in 84K.

There were 19 different contributors. 5 posted more than once. 10 posted last week too.

The top posters of the week were:

1. Broken Gimp HTML Documentation

3 Jan 2000 (4 posts) Archive Link: "gimp HTML docs"

People: Michael J. HammelSteinar H. GundersonSven NeumannSven Neumann

Michael J. Hammel <mjhammel@graphics-muse.org> asked the list:

I built 1.1.14 with gtkxmhtml and the browser seems to work fine, but there doesn't appear to be any documentation included. All the pages say "Sorry but the help file for xxx is not ready yet."

Is there another package I need to download? Or did I just not install correctly from the 1.1.14 package perhaps?

Then Steinar H. Gunderson wrote back, " Some of the pages actually contain information. The text is quite correct -- most of the help files simply aren't written yet. "

Sven Neumann added that "you should be able to find some that have more info then "Sorry..."." He said that things are installed correctly if the blank help pages are showing up.

Michael returned an e-mail saying, "Ok. I just wanted to double check that I hadn't missed an announcement or something. Thanks."

2. A Call For Plugin Maintainance

4 Jan 2000 - 6 Jan 2000 (4 posts) Archive Link: "Call for plugin maintainance"

People: Sven NeumannTom BechDaniel EggerSven Neumann

Sven Neumann queried the list, saying:

on our way from 1.0 to 1.2 we included a few plug-ins that were considered not to be stable enough to be included with a stable release. This was done in the hope that the inclusion into the 1.1 developement tree would encourage people to work on those plug-ins so that they would become stable enough to be released with 1.2.

IMO the time has come to doublecheck what plug-ins do fulfill our needs. We have a lot of unmaintained plug-ins in the distribution. Most of them are however quite small, so fixing a bug or doing small changes (like adding gettext support for example) is not too difficult. However there are a few quite large plug-ins (partially written with obscure coding schemes) in our distribution. Some of them are actively developed and maintained by their authors. But unfortunately we have some obviously abandoned projects in our tree.

My proposal (and I don't think that anyone can really object against it, since it is the only reasonable way to go) is that we search maintainers for those plug-ins and if we don't find someone feeling responsible we move the plug-in out of the stable tree as soon as a bug is found.

I'm not yet sure how this should be organized. I will try to build a complete list of all plug-ins with some information like number of files, codesize, original author, current maintainer and post it here later. Hopefully some people will volunteer to take responsibilities for the abandoned projects.

I propose that this list gets included with the distribution so that people know who to contact.

He also provided a small list of plugins for people to take responsibility for: FractalExplorer, GFlare, GFig, libgck, and Lighting.

Tom Bech delurked, and replied that libgck and Lighting were his plug-ins. He said he was unable to keep them up to date because of the demands of the Real World. He continued, saying:

During this year I've gotten two or three mails about the Lighting plug-in, mostly concerning the broken zooming - which should not be too difficult to fix. None about crashes. I would be grateful if those who do find (fatal) bugs drop me a mail about it, I don't have the time at the moment to actively search for bug reports.

GCK is AFAIK only used in "my" plug-ins (lic, mapobject, lighting) - I will rewrite them to "pure" G* as soon as I find the time.

If someone feels like more actively maintaining the mentioned plug-ins, feel free (and let me know) - I may still do some work on them from time to time, but I can't guarantee it.

Fifteen minutes later he replied to himself, regarding getting no emails about crashes. He said, "this turns out to be a blatant lie. For the record; I did, in fact, get one such mail - the issue was resolved though."

A few days later, Daniel Egger wrote:

Hm, there are two thing that are really annoying me:

-megawidget
-libgck

libgtk, libgdk and libgimp should provide all methods which are necessary to build plug-ins. If they do (and I think they do) then there's no reason for existance of these kludges and they should be removed. If they don't we should integrate the necessary functionality into libgimp and thus provide a straightforward and common way to build plug-ins...

Yosh: Will these changes have any chance to get into the tree soon if I'm providing the necessary patches?

There was no reply.

3. Obscure Font Rendering Feature

4 Jan 2000 - 5 Jan 2000 (3 posts) Archive Link: "[bug?] Baseline when rendering fonts."

People: Andreas JaekelPeter Kirchgessner

Andreas Jaekel altered the behaviour of the Gimp's font rendering function to fix what he saw as a bug. But he added, "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." He explained his 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.

He suggested removing the call to the crop routine, which would be a one-line patch.

Peter Kirchgessner replied that he had encountered the same problem several years ago. He explained that at that time a patch had been accepted, to prevent the renderer from cropping, when the border parameter had a negative value.

Andreas then replied:

Splendit! That is exactly what I need. I've seen the code that does it, but I totally missed it's meaning :)

Thanks for the fast reply. It now works terrific.

I strongly suggest changing the register help text for the text render functions to include a hint to this behaviour. Nobody should have to spent three days searching for that anymore :)

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.