---------- Forwarded message ----------<br><div class="gmail_quote"><div><div class="Wj3C7c"><div class="gmail_quote">From: <b class="gmail_sendername">Igor Novikov</b> &lt;<a href="mailto:igor.e.novikov@gmail.com" target="_blank">igor.e.novikov@gmail.com</a>&gt;<br>
Date: Mon, Apr 7, 2008 at 5:36 AM<br>
Subject: Re: Color swatches<br>To: Olivier BERTEN &lt;<a href="mailto:olivier.berten@gmail.com" target="_blank">olivier.berten@gmail.com</a>&gt;<br><br><br>Hi Olivier,<br><br>Great work! I think we can include the code after additional modification into sK1 as a part of palette manager. The most interested part is a CorelDRAW format, because users can extract some proprietary palettes from CorelDRAW installation (PANTONE palettes for example). It seems this code allows resolving PANTONE colors usage issue into FOSS applications because users will know where to get the palettes and how to convert its. Something like as for MS core fonts for Linux ;)<br>



<br>Regarding registration color I am agreed with you. It should be special color instance. For regular 4-color prepress it could be usual CMYK color but for spot color separation it should be special instance (for ps/pdf generation). We will extend sK1 colorspaces by this color type.<br>


<br>But proposed xml-palette format is complicated. It seems not all applications will support such complex scheme. May be simple well-formatted xml can be more useful as intermediate specification. <br><br>Regards,<br><font color="#888888"><br>


Igor Novikov<br>sK1 Project<br><a href="http://sk1project.org" target="_blank">http://sk1project.org</a></font><div><div></div><div><br><br><div class="gmail_quote">On Sun, Apr 6, 2008 at 6:16 PM, Olivier BERTEN &lt;<a href="mailto:olivier.berten@gmail.com" target="_blank">olivier.berten@gmail.com</a>&gt; wrote:<br>



<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div dir="ltr" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hello!</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">It&#39;s been a while now
that I&#39;ve been analyzing color swatches in different software. Here is
the result of my work: <a href="http://www.selapa.net/couleurs/fileformats.php" target="_blank">http://www.selapa.net/couleurs/fileformats.php</a>
(it&#39;s an update of
<a href="http://wiki.scribus.net/index.php/Talk:New_Colours_Format" target="_blank">http://wiki.scribus.net/index.php/Talk:New_Colours_Format</a>
with another
presentation). If someone has informations about other formats or
precisions about these ones, I&#39;d be happy to add it to the list...<br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">I also started writing
a conversion script (attached). For now, it can only read pal (riff),
aco, act, acb
(adobe and autocad unencrypted only), ase, acf, bcf, clr (colors only),
cpl, qcl, bcs, cs. No write function is there yet. It returns a
dictionary with the content of the swatch. All values are kept as in
the original file, that&#39;s why there&#39;s a &#39;orig&#39; field in the dictionary.
I&#39;m pretty new to python programming so my code is probably not
optimal...</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Now some thoughts about
color swatches in general and about the CREATE draft:</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Registration color</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">IMHO, this shouldn&#39;t
come in a color swatch file. It&#39;s a &quot;system&quot; color, just the opposite
of
&#39;None&#39;. It depends of the colors used in the document. If you&#39;re using
only cyan in your document, registration will be 100% cyan. If your
document contains only magenta and yellow, registration will be red.
And if you have spot colors, registration won&#39;t be C=100% M=100% Y=100%
K=100%. In other words, registration can&#39;t be defined out of the
document&#39;s context. Registration should just be added in the software&#39;s
color list for any press work.</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Color swatch draft
<a href="http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Draft" target="_blank">&lt;http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Draft&gt;</a><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">The name and space
attributes shouldn&#39;t be mandatory. A color doesn&#39;t need a name to come
into a palette and many palettes are just a arbitrary &quot;geometrical&quot;
division of the possibilities of color model. When you have #003399 in
a palette, it&#39;s not because it looks like anything in real life, it&#39;s
just because its neighbors are #003366 and #0033CC. It just shows
different possibilities of RGB, whether you&#39;re using sRGB or AdobeRGB
doesn&#39;t matter. The same applies to &quot;Black 20%&quot; (or C=10% M=20% Y=30%
K%). There are a lot of such palettes where neither the name or the
color space have any importance. By the way, Lab and XYZ don&#39;t need any
color space since these are device-independant models.<br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">That model also lacks
swatch informations (name, copyright, license, ...) and swatch-wide
settings (&quot;all rgb values are in Adobe1998 color space&quot;, &quot;all color
names start with &#39;PANTONE&#39; and end with &#39;C&#39;&quot;, ...).</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Olivier<br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"></p>
</div>

</blockquote></div><br>
</div></div></div><br>
</div></div></div><br>