On Thu, Nov 29, 2001 at 03:17:51AM -0800, Jay Cox <jaycox@xxxxxxxx> wrote:
> > pretty strict definitions of these). If a photo doesn't exactly
> > match the screen colours ("which screen colours, anyways") this
> > is often not a reason to not use gimp. If a logo colour can't be
> > reproduced, however, it keeps Gimp from being used.
>
> You should not create a logo requiring "Logo Colours" in a program such
> as photoshop or gimp. You will get superior results using a vector
> based application such as illustrator.
That's what I was told, too (together with: many people do it with
photoshop anyways ;)
> Sometimes you will need to match a logo captured in a photograph to a
> specific "logo colour" , but the first step would be to convert your
> photograph to CMYK.
But how critical is that process? Do you think that my main point - cheap
conversion to cmyk in the tiff/eps-plugin(s) - would really ease life and
would enable gimp to enter prepress world (even if not at all perfect)?
> "Logo Colours" (aka spot colors or PMS colors) can already be used in
> gimp if you are only using one ink at a time. Just save your image as a
> grayscale tiff and place the image in quark using whatever ink you want.
What about the clipping path, though? I'd guess you want to overlay these
layers often.
> are not usualy working with a logo. Usually you are trying to match a
> color in a photograph that is not representable in the CMYK color space
> Any image that you would want indexed "Logo Colours" for would be better
> off handled in a vector based program such as illustrator.
I was told that trapping can be done with expensive plug-ins for photoshop
only, which would make sense, since trapping is (AFAICS, no idea actually)
not really well-defined for photos, what users would buy such a trapping
plug-in for photoshop?
> In my experience people don't use gimp (or photoshop) for logos
> (I mean for print work, of course the web is a whole different story)
But gimp already works fine for the web, so that's a problem ;)
> I am not certain, but I think that the rgb->cmyk conversion is not done
> by quark, but by the postscript rip when you print your file.
That would nicely explain why it "looks like crap".
> setting the colour profile to sRGB in gimp is the wrong fix. There
> should be a setting on either quark or the rip that tells it what color
> profile to use for images that have no assigned profile.
Unfortunately, users usually don't have control over the rip. I guess
whatever rip is used just uses it's defaults for RGB. quark is a difefrent
story - what if quark doesn't have such a setting?
But I think that acse would be rather irelevant once we have CMYK in tiff.
> > can't create this kind of paths, nor can it save it.
>
> The industry standard way of saving raster files that have spot channels
> in them is the DCS file format (A very close cousin of EPS).
I knew eps couldn't do it (directly ;).
Ok, prepare for:
REVISED CONCLUSIONS (ordered my importance).
1. implement CMYK saving in tiff and eps.
2. enhance tiff(?) & eps to save all channels & paths in whatever format
is actually understood (DCS for eps). one path must be marked as
clipping path (e.g. by name "Clipping Path" or by some parasite
(gimp-clippath on the image containing the ascii form of the path
tattoo or somesuch).
3. (optional, but important) finally enhance the paths to be multipart,
contain holes etc. simon? siiiiiiiimoon? ;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
