- 1 Overview
- 2 Use Cases
- 3 Swatches in SVG/Inkscape
- 4 Mockups
- 5 Software Support
- 6 References
This page is for discussing the concepts around swatch books, for Inkscape and any other programs, and what things users might want.
Feel free to contribute here, on the mailing lists, or in our Jabber/IRC chat rooms.
What is a Swatch Book?
Basically a "Swatch Book" is a collection of swatches that an artist or designer might put together for reference during a project.
Although a large number of people are familiar with various commercial spot color books, a swatch book is not limited to just colors. Decorators, designers and others often have books with more than simple color chips. That leads into the question of just what is a 'swatch' - JonCruz
What is a "Swatch"?
In general artistic design work, I normally hit a different definition of "swatch". It's not just a color, it's a "sample" or "material". It could be a simple solid ink color, or it could be a heavy plaid cloth. Moving into software, "Gold" is another good example. "Gold" is a texture, not a color (just ask the Blender artists out there). From an artist/designer's viewpoint, they tend to think in terms of a swatch book as "a collection of things I've pulled together to use for this project". I *think* some of the problem comes from saying "Pantone swatch book" and such but not keeping in mind that it is just a subset of general "swatch books". That is, it is a "swatch book but with only solid paint swatches". Then again... I have used foil Pantone books, so those definitely fall into the "material, not just color" category. - JonCruz
Some examples I've seen in swatch books are
- Spot color samples (Pantone, Trumatch, Focoltone, Toyo, etc)
- Counter material
The key here might be to think "material" instead of just "color". Although one might work with just colors, others might want to extend to a bit more.
I have seen a need come up many times for shared collections of disparate resources such as colors, textures, patterns, etc. Others on some different projects think it might be nice in the long run, but that they're not looking at jumping in themselves in the immediate timeframe. Some discussion has been done involving the people in CREATE, but the colour file format is as far as the common interests go at the moment.
Once the format has been roughed out and some working prototypes are in place, we'll see other projects revisiting for collaboration. So first we just need to collect up general use cases and implement a rough draft.
And think of the use case. Say a comic artist is working on a project. He would probably want a "swatch book" for each of his characters, and perhaps one combining them. Then he might also want to add a book per character per lighting condition ("daytime", "nighttime", etc). When he went to use it, he might like to just select "Fred's skin" and apply it to an area. Then "Fred's shirt" for another. Those might just be simple RGB colors, or the skin might be a simple gradient and the shirt might be a checked pattern.
However... the artist most definitely would benefit from being able to define those books once and then just reference them from each of the programs he uses to create things. - JonCruz
I think it would also be good if we could educate the comic artists on SVG Blend modes work, this way there would be no need to have separate color swatches for time of day. You could easily overlay a colored/gradiated rectangle within a frame and use multiply or another blend mode. Then again, that's also a preference of workflow.- ScislaC
Swatches in SVG/Inkscape
For SVG work, we'd probably like to be able to include gradients and patterns also. "Brushes" might also be nice... but I think those are something a bit different. For the apps I've seen that differentiate brushes from patterns, brushes get to be more of blobs of complex procedural code. - JonCruz
This involves more than just the swatches, but I found the brush weight profiles in Xara X[1|treme] quite intuitive. Basically it's now doable in 0.46 with LPE and an auxiliary shape that defines the variable brush weight, but Xara's simple dropdown of pre-defined profiles worked quite well. Just a thought. - jegHegy
I think all mentioned uses of swatches are applicable. As for brushes, yes, I think those would be great as well. If we can have a standard cross-application compatible way to include those and then leave it up to the applications to implement how they want to utilize them, that would be optimal. In addition to brushes, having a symbols library implemented in a swatch book would also be greatly helpful. - ScislaC
Artists sending their work to a screen printer need to work in spot colors for easy separation, so they can avoid additional "artwork fees" by the provider. Usually, the provider also has a set of standard colors that they use, charging more for custom mixing. --Cohort 05:06, 25 December 2009 (UTC)
The purpose of this table is first of all to find what apps support each feature, so that we can then look into each of those to make sure that we support everything that each app needs to be sharable in a swatchbook.
Please note that the features across the top will probably change as we gain more information. Also what gets entered into each cell will change once we have a better idea what's going on.
|Inkscape||yes, rich||yes||limited||yes, vector||Yes, as of 0.46+Dev||not really||?||yes|
|GIMP||yes||yes||yes, rich||yes, bitmap||?||yes||?||?|
|Scribus||yes||yes (1.5)||yes||yes, bitmap, vector, all Scribus objects||no||no||yes (1.5)||limited to document|
The intent is to exchange color in the format worked out by CREATE
A few additions might be made, but only in a manner that won't break use of that spec.
A 'palette' is a collection of colors. Many different approaches and formats have been used for this.
|aspect||GIMP .gpl||Adobe .aco, .acb, .act, .ase, .acf, .bcf, .clr||AutoCAD .acb||ColorSchemer .cs||Corel .cpl, .xml (X5)||ICC named color .icc||OO.o .soc||QuarkXPress qcl (+cui)||RAL .bcs||RIFF .pal||Scribus .xml||VivaDesigner .xml|
Gradients in SVG can be expressed as a subset of those supported by GIMP once shape/coordinates are separated. That is, pulling off linear, radial, etc.
In the GIMP UI there is a "blend" tool, and one of the inputs is "Gradient". "Shape" is a different input.
|Segment end can differ from next segment start||N||Y||N||N|
|Adjustable segment midpoint||N||Y||Y||N|
|Opacity in color||N||Y||N||Y|
|Opacity in color stop||Y||N||N||N|
|Opacity as stops separate from color stops||N||N||Y||N|
|Fixed color stop||Y||Y||Y||Y|
|FG color stop||N||Y||Y||N|
|FG+A color stop||N||Y||Y*||N|
|BG color stop||N||Y||Y||N|
|BG+A color stop||N||Y||Y*||N|
|Blend spherical +||N||Y||N|
|Blend spherical -||N||Y||N|
|HSB cw interpolation||N||Y||N||N|
|HSB ccw interpolation||N||Y||N||N|
So a GIMP format gradient is SVG compatible if:
- the end stop for each segment matches the begin stop for the next segment
- the midpoint of each segment is centered
- the color chosen is proper (need some work here)
- the blend is limited to only linear
- the coloring mode is limited to only RGB
|Conical (sym)||N||Y||Y (1.5)|
- My post to the CREATE list on Sep 27, 2007.