From koffice  Thu May 02 16:34:50 2002
From: Thomas Zander <zander () planescape ! com>
Date: Thu, 02 May 2002 16:34:50 +0000
To: koffice
Subject: Re: pantone color
X-MARC-Message: https://marc.info/?l=koffice&m=102035773516882
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--T4sUOijqQbZv57TR"


--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 02, 2002 at 05:36:46PM +0200, Thomas Diehl wrote:
> On Thu, 2 May 2002 17:10:07 +0200, Thomas Zander wrote:
>=20
> >I have to disagree here; the photo editing application knows just about =
the=20
> >CMYK colors and converting them to and from RGB.
> >The steps you describe are done later in the process.
>=20
> Yes, partly this occurred to me later as well (although I have an
> extremely hazy idea of the programming side of this anyway).
>=20
> >Here is a short summery;
> >* splitting the CMYK into seperate channels; either the paint program, o=
r the
> >print software. but that is a breeze since its just simple data manipula=
tion.
> >* The dots and their distribution as you say. This is the screening proc=
ess
> >and is printer dependent. This is done by a RIP or another special machi=
ne.
>=20
> Values for lpi, dpi, halftone type, and even dot patterns can be set in
> (at least some) bigger layout programs which also try to bypass the
> system drivers as much as possible and write their own PS.
Right, this is stuff you can put into PS.  This means that Qt would have to
do that and KDEPrint will have to sent that stuff.

> But since
> the RIP (at least high end RIPs) may again overwrite many of these
> settings I'm really also pretty hazy about which part of the machinery
> is exactly doing what in the end. I'm just happy if it looks okay. ;-)

DPI is implied since you put dimentions in your DTP application when you pr=
int
an image.
The other stuff is indeed done on the RIP for a simple reason, you don't wa=
nt
to bother the graphics man (in this case you :) with it.  Plus that for dif=
ferent
printers different settings are optimal.  Even for the same kind of priner =
a=20
new pair of drums (thats for toner based printing) means you may want to tw=
eak=20
these settings. But then those things are done on the streamer if you are i=
nto
these things..
Anyway, this is fun stuff but not for KDE.

> But, as you say, all this is not really necessary for a basic
> implementation anyway.
Nope :)

> >Bottom line; Krita should know about 4 channel images and should be able=
 to=20
> >convert to and from RGB.=20
> >
> >Optional are ICC profiles for color management.  The basis of this is si=
mple,=20
> >the implications of using ICC profiles is huge. And wonderful :)=20
>=20
> Have you looked at http://www.littlecms.com/ ? Would be very interested
> to know if this could be usable for KDE/KOffice sometime / somehow.

I'm afraid I won't find time for that anytime soon :)=20

--=20
Thomas Zander                                            zander@earthling.n=
et
The only thing worse than failure is the fear of trying something new

--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE80WqqCojCW6H2z/QRAhO1AJ9l2zEgIzOFncZ++qDgD5XFV3b/8QCfRpNh
Kf8Onz5sq9qP/mPhCjNgBeU=
=GI/t
-----END PGP SIGNATURE-----

--T4sUOijqQbZv57TR--