peter sikking wrote:
> Now what about that prepress. I think it is fairly safe to say
> that scribus' vision is to be prepress-king and GIMP should watch
> it not to want to overlap too much in that department. Everything
> in the above examples that reeks of newspaper, publications or
> multiple pages is a job for scribus. They want to do this.
As I understand it, Scribus is not a pixel editor, it is
a page layout package, rather a different thing altogether.
So you're saying that Scribus should add a pixel editing
package to their application, so that they can support CMYK
and other non-RGB color spaces, duplicating an awful lot
of what's in GIMP ?
> The vision does speak about creating original art and I am all for
> it to bring this original art to the printing press. And not via
> the print dialog (I am also mr. openPrinting) but those printing
> presses that have operators. From the description above you can
> see what is should be like: first you create the art, then you
> bring it to the press. Mix master tape (in rgb) and then cut
> the lp (in cmyk).
I really don't think people working in the graphic
arts are going to want to master two different pixel editing
packages, simply because one of them doesn't support anything
other than RGB. If they're in the Linux sphere, then I guess
they need to go and look at using Krita instead.
[ ie. handling CMYK and other colorspaces is a superset
capability, with RGB being a subset, and the colorspace is orthogonal
to the pixel manipulation capabilities ]
Gimp-developer mailing list