Gimp Traffic #14 For 18 Feb 2000

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

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."

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?

One problem that people mention on comp.graphics.app.gimp 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: eps-loader-prologue.ps and eps-loader-epilogue.ps ?

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"

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.

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 gimp-developer@scam.xcf.berkeley.edu mailing list. All kinds of contributions are accepted. Patches that you wish to go into the distribution should also be uploaded to ftp://ftp.gimp.org/incoming. Follow the rules there for naming your patches." He also noted that bugs should be reported at http://www.xach.com/gimp/news/bugreport.html

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).


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	9 Feb 2000 - 14 Feb 2000	(5 posts)	CMYK Support In The Gimp
2.	10 Feb 2000 - 12 Feb 2000	(5 posts)	Error When Loading EPS Files
3.	11 Feb 2000	(2 posts)	Patches for Gimp 1.1.17
4.	11 Feb 2000 - 12 Feb 2000	(7 posts)	Patch For Print 3.0.6

Gimp Traffic #14 For 18 Feb 2000

By Alex Harford