On Thu, Nov 29, 2001 at 03:17:51AM -0800, Jay Cox <[EMAIL PROTECTED]> 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      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED]      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
Gimp-developer mailing list

Reply via email to