On Fri, Nov 30, 2001 at 03:38:10AM -0800, Jay Cox <jaycox@xxxxxxxx> wrote:
[cmyk comversion]
> Where I work it is a very critical process.
Any tips here? If gimp would support CMYK on-screen, how would the users work
be different? Do users actually adjust CMYK themselves or do they just draw
using predefined CMYK values?
I mean, is the principal problem the missing CMYK colours in RGB, or is
the principal problem the "looks the same on-screen as on print". The
latter could be solved largely outside the gimp (tiff plug-in), the former
obviously not.
> with less compulsive designers it is much less critical. This feature
> would not get gimp into prepress houses, but might help out the casual
> designer who is preparing artwork for a short print run.
Would it be worth it? ;)
> The most common/best way to do trapping that I have seen is to trap
> after the rip using a program like creo/scitex full auto frame (which
> isn't quite as auto as the name implies:).
Obviously, as only then you have the full image. Hey, the new postscript
can do in-rip trapping ;-> (adobe claims yet another revolution ;)
> even if it doesn't have a setting I dont think we should modify the
> default behaviour of gimp to work around a bug in quark :)
well, it depends on wetehr you call this a bug or not. if quark lacks the
functionality (if!) to bind profiles to images it's not a bug ;)
> > 3. (optional, but important) finally enhance the paths to be multipart,
> > contain holes etc. simon? siiiiiiiimoon? ;)
>
> How is #3 optional? :)
Well... it's the most difficult part. 1 and 2 could probably be done even in
gimp-1.2, #3 is a problem. Also, if you don't have clipping paths you still
can print many photos ;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
