Again, thank you for educating me on these principles. This really is great stuff! Just the type of insight that I need. I am sure that many of us struggle with production issues and it would be good to develop design patterns on how to overcome them.
In response to Luigi's follow up post, let me describe what I have done, and ask your opinions (and indulgence) as to its usefulness. Let me preface all this by pointing you to an old video from AT&T archives, now to be found on YouTube where Brian Kernighan describes some of the distinctions of Unix. Although the entire video is worthwhile even at 27m+ long if you just want to skip to his part, that starts at the 4m09s mark. It is a nostalgic (but still valid) look at the elegance of pipes and redirection. Okay, what I have done is create two 'bash' scripts which rely heavily on 'sed' to massage the text data retrieved using 'w3m' to create suitable "colo-imp-ral.mkiv" (RAL Classic colours; 223 colours) and "colo-imp-pantone.mkiv" (Pantone Coated colours; 1341 colours) files on demand using the values found on Carlos Cabo's rgb.to website. The generated file for the RAL colours includes both the RAL number and the *English* name of the colour; one can easily modify the script to use a different language version of the name if so desired. So, for example: \definecolor[ral1000] [h=cdba88] \definecolor[greenbeige] [h=cdba88] The script for the Pantone colours will only use the published name, whether it have a name or number or both. So "Pantone Coated Orange 021 C" will be found in the file as: \definecolor[pantoneorange-021-c] [h=fe5000] and "Pantone Coated 801 C" \definecolor[pantone801-c] [h=009ace] I won't, for the time being at least, publish the colour files in case there is any issue about the proprietary nature of colours, but offer up these two shell scripts. With these scripts one can generate the colour files as needed for personal use. If Hans feels that these scripts are appropriate to be published on the list, then I am happy to do so. I will wait to hear back. Best wishes. PS: I can already see some inconsistency in the sed processing as there is no dash prefix before 801...*sigh*. Will have to work on that ;). On 06Apr15, Henning Hraban Ramm wrote: > Spot colors for printing rely on manufacturers that produce those inks/paints. > The existing palettes are defined by (or in cooperation with) manufacturers. > There exists nothing like open source paint recipes, AFAIK, so it would make > no sense to define an open source (i.e. freely licensed) palette/system of > spot colors. > > Of course it’s possible to define a system of (anyhow) matching colors. But > that’s so much a matter of taste and application that I wouldn’t start with > such an enterprise. > There are some good online tools that help you finding matching design > colors, at least for (s)RGB, e.g. Adobe Kuler or paletton.com. > If you need spot colors for printing, you need a (digital or physical) > palette from the manufacturers. > > > Greetlings, Hraban -- ---- Pavneet Arora m: 647.406.6843 Waroc Informatik t: 416.937.9276 ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
