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

Gimp Traffic #14 For 18 Feb 2000

By Alex Harford

Table Of Contents

Mailing List Stats For This Week

We looked at 103 posts in 312K.

There were 40 different contributors. 18 posted more than once. 26 posted last week too.

The top posters of the week were:

1. CMYK Support In The Gimp

9 Feb 2000 - 14 Feb 2000 (5 posts) Archive Link: "CMYK when?"

People: Carl B. ConstantineRobert L KrawitzKelly Lynn Martin

Posting for a friend, Carl B. Constantine asked when CMYK support would be available. He added, "I looked at the Gimp-plugin on source forge and it mentions CMY printing for some inkjet style printers, but not sure if this is the same thing (not really knowing a whole lot about this)." Robert L Krawitz asked for more details from Carl's friend, and added:

Hi. I'm the project lead for the gimp-print project on sourceforge.

CMYK is a bit of an oddball subject. Partly this is because there are so many variants (CMY, CMYK, CcMmYK, CcMmYy, CcMmYyK), and partly because (to the best of my knowledge) this color space is really only useful in the context of specific output devices, which is what the print plugin deals with.

Kelly Lynn Martin also replied to Carl, saying, "Full CMYK (that is, at least 8 bits per channel, not the twiddly 2-bit stuff you deal with working on the printer drivers) is _absolutely necessary_ for GIMP to be viable for prepress work."

Replying to Robert, Carl came back with more information:

Ok, I asked my friend for more details, and here is what he said:

"My main concern is support for TIFF images saved in CMYK format.... Our advertising agency works in this format, and currently I have to ; get the image, convert using a corel product from CMYK to RGB, play with an image in the Gimp, convert back through the corel program and send it back, with image quality loss every step........ Of course this is probably going to necessitate a major change in the core, because Gimp currently works only with RGB colour palettes..."

I'm sure others have similar concerns/wishes so it's good to pass all this on. Hope we can see something soon...1.3 maybe?

There was no reply.

2. Error When Loading EPS Files

10 Feb 2000 - 12 Feb 2000 (5 posts) Archive Link: "loading EPS files"

People: Austin DonnellyMichael NattererPeter KirchgessnerNick Lamb

Austin Donnelly wrote:

One problem that people mention on quite regularly is that gimp says "load failed" on some EPS files.

This happens when the EPS file doesn't have a "showpage" command on the end of it.

Actually, EPS files probably shouldn't use an explicit showpage, since they're supposed to be embedded. But users like to be able to just "lpr foo.eps" and have some output generated, and Adobe's Encapsulated PostScript File Format Specification (version 3.0, 1 May 1992) says that showpage is allowed (see page 10, section "Redefining showpage"). So in a bid to reduce the number of confused users, I think gimp should continue to produce EPS files with a showpage at the end (and rely on the embedding application to correctly define away showpage).

However, this still leaves the question of how to correctly load an EPS file. Currently, we just present the file to gs pretty much verbatim (ie, with no embedding). This works only for EPS files that have an explicit showpage in them. Some don't, eg those produced by Aldus Freehand 8 on Mac.

The correct way to get gs to render the EPS file is to provide it with a prologue, the file itself, then finally an epilogue.

Now, the only question remains how to add this harness code around the EPS we want to load. The simplest is just to copy the EPS to a temporary location, sticking the prologue and epilogue on as we go. This is tedious, since people often want to load large bits of PostScript, and we don't want the overhead (in terms of both time and space) of copying the thing.

Luckily, gs allows multiple files to be listed on the command line.

So, where's a good place to put a couple of plugin-specific data files, namely: and ?

Michael Natterer replied that "All other plugins with need auxilliary files have their own directories."

Peter Kirchgessner replied twice to Austin. In his first, he suggested "hard-coding it into the plug-in and creating temporary files on runtime that are passed to gs"

But Nick Lamb objected:

Even given that we have a secure place to write temporary files (in the user's private .gimp directory probably .gimp/tmp/ by default) this sounds like an unnecessary and dangerous mechanism for something we could just stick in .../share/gimp/somewhere and forget forever.

Also, if (for some crazy reason) there is a local benefit in using a different prelude and conclusion then it's easy to fix them, no?

In his second reply to Austin, Peter Kirchgessner also suggested, "another possibility would be to call gs with an additional -c showpage to force a showpage command after interpreting the file. Ghostscript then will generate two pages for files with a showpage instruction. The second (empty) page then must be dropped when reading data from ghostscipt." There was no reply.

3. Patches for Gimp 1.1.17

11 Feb 2000 (2 posts) Archive Link: "Some update to gimp sources"

People: Cosmin TrutaGarry R. Osgood

Cosmin Truta wrote that he had made some updates to the jpeg plug-in to save it in IJG's format, and wanted to know how to get his patch added to the Gimp. "It is the very first time when I try to send a patch to some GNU software, so I don't know exactly how to do it. I sent this message to this List now; if there is another, better way to contribute to contribute to GIMP, I would like to know about it :-)"

Garry R. Osgood thanked Cosmin for his contribution, and quoted the HACKING file from Gimp CVS: "Please submit patches to the mailing list. All kinds of contributions are accepted. Patches that you wish to go into the distribution should also be uploaded to Follow the rules there for naming your patches." He also noted that bugs should be reported at

4. Patch For Print 3.0.6

11 Feb 2000 - 12 Feb 2000 (7 posts) Archive Link: "Patch for print 3.0.6"

People: Robert L KrawitzSven NeumannSHIRASAKI YasuhiroSven Neumann

Robert L Krawitz posted a patch, and wrote, "I'm having to release a Print 3.0.6 due to a fairly serious bug found by Panos Katsaloulis. The specific bug is that monochrome printing in grayscale does not work properly." Sven Neumann applied the patch, but added, "I have changed the code so that the "File" pseudoprinter is initialized which makes printing to a file possible again. Sorry for fiddling with "your" code, but you did not seem interested in fixing this after it was reported several times." Robert was surprised by this news, and said: "What was this? I wasn't aware that File didn't work. Most likely I missed something somewhere..."

In his previous post Sven had also asked, "BTW, is there any interest from your side to implement the usage of the image resolution? It's a shame (if not a bug) that the Print plug-in ignores the resolution info." Robert replied, "That's a useful suggestion, although it won't make 3.0. I envision it as something like a third radio button for the Scaling option which would be something like "[Print at] Natural Resolution". Actually, we're redesigning the GUI, so this is very timely."

SHIRASAKI Yasuhiro also replied to Sven, and asked, "Will we unmark printer names N_() tagging in print.c?" Robert replied, "I don't have any plans to touch this stuff in 3.0. 3.1 and 3.2 are going to be somewhat different." Sven also replied to SHIRASAKI, "I have done it once, but didn't check it in after I realized that lots of translators had already provided localisation for those strings. I don't know if an "EPSON Stylus Color" is called like this all over the world, so there may be a need for localisation." Robert added:

A lot of printers (as is the case with many consumer electronic devices) do have different model numbers elsewhere. Unfortunately, though, the model numbers might cross linguistic boundaries. It's typical for North American models (US and Canada; I don't know if Mexico is considered North America by manufacturers) to have one name and Europe to be something else (thus, English and French, at least, will have two different model names).

There definitely is a need for localization, but the appropriate localization may not match what we have available.

Just to make matters worse, sometimes there's no absolute one to one correspondence between models; there may be minor local firmware differences, for local preferences or to work around patents in one country (photographers: note the Canon EOS 5 vs. A2E, which has a few minor differences and one not so minor feature missing on the A2E).

There were no more messages in this thread.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.