[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-artists
Subject:    Re: K-ARTIST: icon guide
From:       Wade Olson <wadejolson () yahoo ! com>
Date:       2004-01-30 15:37:17
Message-ID: 20040130153717.16927.qmail () web40003 ! mail ! yahoo ! com
[Download RAW message or body]

Ante,

I think that this is a great start.  I can't critique the content, but am glad that this work is
gaining momentum.

Some thoughts:
1) Some simple tutorials, tricks of the trade, and faq about vector programs will be nice.  Alot
of people that have previously specialized in Photoshop and GIMP may have hesitation about
learning the various vector programs.

We may also want to list the program options, as displayed on:

-http://www.w3c.org/Graphics/SVG/SVG-Implementations.htm8

and reference other svg tutorials.

2) To see how others approach icon style guides, if not already done so, we should review sites
such as:
-http://developer.kde.org/documentation/standards/kde/icon-style.html
-http://www.sapdesignguild.org/resources/icon_cookbook/
-http://developer.apple.com/documentation/UserExperience/Conceptual/APStyleGuide/AppleStyleGuide2003.pdf
-Any gnome style guides that are recent

Such sites may help us with and topics we've skipped.  General style guides (such as Apple's) can
still be useful.

Does anyone know of any other useful references?

3) We should keep any accessibility issues in mind:

http://accessibility.kde.org/

For example, is the cystal color palette distinctive to forms of color blindess?  Is there any
palette choice conflict? (you do mention briefly below)

4) Once in place (after Ken's supposed intern does all the dirty work), this work should be
visible and obvious, and not tucked away on KDE's many sites.

--- Ante Wessels <vitanova2@softhome.net> wrote:
> Hi,
> 
> A first concept for the new icon guide. I took the old icon guide, rewrote 
> some things, and put square brackets [ ] around the stuff the needs 
> discussion or can be thrown out. Many parts look ugly, yet, since some 
> discussing will take place it is useless to make it all too pretty now.
> 
> Well, if there ever was a time for feed back, it is now!
> 
> (It already has some wiki lay-out such as !!! )
> 
> Cordialemente,
> 
> Ante
> 
> 
> 
> ******
> The most up to date info for kde artists can be found at the wiki:
> 
> http://kde.ground.cz/tiki-index.php?page=KDE+Artists
> 
> Scripts for kde artists, like svg2png4kde, add border, add drop shadow, change 
> filename, file conversion:
> http://home.uwnet.nl/~vita/linux/index.html
> 
> Web course italian, poem generator, poetry, stories and visual art:
> http://home.uwnet.nl/~vita> A first concept for the new icon guide. I took the old icon guide,
rewrote some things, and put
> square brackets [ ] around the stuff the needs discussion or can be thrown out. Many parts look
> ugly, yet, since some discussing will take place it is useless to make it all too pretty now.
> 
> Well, if there ever was a time for feed back, it is now!
> 
> (It already has some wiki lay-out such as !!! )
> 
> 
> !!!Introduction
> 
> Welcome to the KDE Icon Guide. This document attempts to specify the look of the icons for
> applications used in KDE. KDE uses the Crystal SVG icon set originated by Everaldo. The goal of
> this guide is to provide some rules-of-thumb for artists to create their icons so that KDE
> software will have a consistent look-and-feel and won't look like patchwork. The guidelines in
> this style guide are meant to be applied on all icons in KDE-CVS.
> 
> Did you ever see a traffic-sign showing a photorealistic train? Certainly not: traffic-signs
> were designed to make it easy to recognize them and get their meaning very fast.
> Therefore they are kept simple: They are very plain, symbolic and consist of very few colors.
> Icons used in desktop environments have a similar aim: they should be designed in a way that
> makes it easy to get their 'message' fast. On the other side the typical user wants to have a
> desktop that doesn't look ugly or too technical.
> 
> The current look of the KDE-icons is a compromise between icons that look very symbolic (like
> those icons used for the MacOS) and near-photorealistic icons (like those icons used by
> Windowmaker or Gnome e.g.). The design that results from these guidelines can be described as
> being "cartoonish".
> 
> Let's take a look at some pitfalls in icon-making.
> 
> 
> 
> 
> 
> 
> 
> 
> !!!Pixels and Vectors
> 
> There are 2 ways to draw icons, make pixel icons or make vector icons. Both ways have their
> pitfalls. Understanding these pitfalls will make you a better iconmaker.
> 
> Icons used to be made as pixel icons. Often the artist would make a 32x32 icon, and then scale
> it down to 16x16. Scaling the icon down makes it fuzzy, the artist had to repair it. Sometimes
> the 32x32 icon had to be simplified in order to make it possible to scale it down. Going back
> and forth between the icons the artist produced two icons that looked the same.
>    Each time a new size is added a new icon has to be made. The number of icons in a set can
> become so big, the icon set becomes unmaintainable. Enter vectors.
> 
> Vector images can be scaled. This way, theoretically, an artist just has to make one icon.
> Unfortunately, at small sizes every pixel counts, you can't leave scaling to small sizes to a
> program. You need hand-optimized icons for the smaller sizes anyway. Another problem with vector
> icons is that they are often made at the spacious 128x128 size. The artist gets lost in space,
> starts to make landscapes full of details. Scaled down you just get a blur... Artists new at
> icon-making miss a historical background, they did not learn in the pixel era to keep it simple.
> 
> With a few simple exercises we want to give you a feel for the importance of keeping icons
> simple. First some words about recognizability. Let's pretend we are old-school philosophers,
> take one principle and explain the whole icon-world from it.
> 
> !!!Icons are Recognizable
> 
> They should be recognizable at all levels.
> 
>  - The Symbolic level. A notebook and pencil together are symbolic for a simple text editor, a
> notebook and a fountain pen for a more advanced text editor. A car, a bucket and a brush
> symbolize an application to wash a car.
> 
> Icons never walk alone, in fact, they come in floods. Traffic rules are needed. In kde for
> instance, the K and the gearwheel are reserved for the desktop as a whole and the core elements.
> 
>  - The Object level. Objects often have an archetypal form and deviations from that form. You
> can have a classical watch or a swatch. Someone looking for a tool to set the system time may
> overlook the swatch, he will not overlook the classical watch.
> 
> Each one of us has an other image of a classical watch in his mind. You may have experienced
> being in a supermarket, looking for a certain product, while having the wrong image of it in
> your mind. It is hard to find then, while with the right image in mind it is spotted instantly.
> For this reason the artist should not follow his own image and paint it as he sees it in his
> mind's eye. He should bring it down to the essential elements. Pictogramms are often cartoonish.
> Instantly recognizable for all.
> 
> It is time to mention the general design principle KISS - Keep It Simple, Stupid. While artists
> may love to paint beautiful paintings, icons need simple symbols. Think Icon, Not Painting. Be a
> follower of KISS.
> 
>  - The Shapes level. You travel by train to a big city you do not know yet. You pass the
> industrial outskirts, you see many non-descript buildings, and forget them immediately. On the
> other hand, if you ever saw an image of the Empire State Building, you will always recognize it.
> Some shapes stand out, others do not. You will not mistake a Mondrian for a Monet.
> 
>  - The Assembly level. Shapes together form an assembled shape. This shape too can stand out or
> not. Icon sets may enhance the assembly shape with an outline. An example of an assembly shape
> is the skyline of New York.
> 
> Here we can mention the empty shape too. You probable know the images with two faces looking at
> each other, seen en face. Some see the two faces, other see a chandelier in between them. With
> two wine bottles, one a bit in front of the other, in between them you can see a beautiful v
> like form. The empty shape is the glue in images. It too can stand out or not.
> 
>  - The Sizes level. Now we scale the image down to 16x16. All details are lost, but that should
> not be a problem. Do we still recognize the notebook and the pencil? Can we distinguish the
> pencil from the fountain pen? Do we exclaim: Hee, a miniature Empire State Building? Do we
> recognize the skyline of New York? Is it, though smaller, basically the same image?
> 
> With this in mind, log out from kde, start an old-school windowmanager, in which the icons were
> drawn pixel by pixel. Poke around, look at the bigger and the smaller icons. Which ones are
> good, which ones are not? Do these rules apply, can you make better rules? Then log into kde
> again, look at the icons. What do you see?
> 
> !!!Icon Boot Camp
> 
> Want to learn to draw icons? Enlist in Icon Boot Camp!
> 
> !!!* First Assignment *
> 
> Make an icon for an application to wash a car (or any other application).  Here is the
> specification: it has to be a pixel image, size 32x32 pixels, in black and white on a
> transparent background. Black and white icons are hard to make, you can not use colors to set
> objects apart. Making a black and white icon may be the most valueable learning expercience you
> ever get (in the icon field...). For pixel images you can for instance use the GIMP.
> 
> Ready? Save the image as a png.
> 
> Next step. Scale the image to 16x16. It will need repair now. Repair it and save it under a new
> name. Does it look the same as the 32x32 icon? Of course the bigger icon can have more detail.
> But overall the icons have to look the same. May be you have to simplify the bigger icon a bit
> to make it possible to scale it down. Play with it till you have Visual Consistency. You will
> have noticed that every pixels counts, especially in the 16x16 icon. Making black and white
> icons really learns you to Keep It Simple.
> 
> !!!* Second Assignment *
> 
> Now add color to the 32 icon. Since colors can be used to set objects apart, objects can overlap
> more easily, it will seem you have more space. A totally other design is possible. Keep a 1
> pixel transparent border around your drawing. Then make the 16x16 icon, also with transparent
> border, and work on both till you have visual consistency.
> 
> Take a look at the 16 icon. How many major objects does it have? (fi car, bucket, brush) How
> many sub-objects does the biggest major object have? (fi car: body, 2 wheels, 2 windows) How
> many sub-objects does the smallest major object have? How big are these sub-objects, how many
> pixels do they use? Is the count the same for the 32 icon?
> 
> You now have an idea about how many objects and sub-objects an icon can have.
> 
> Still got the 1 pixel border? Now add a black outline to both icons. How do you like them best -
> with or without outline?
> 
> !!!* Third Assignment *
> 
> Redesign the icon as a vector icon, for instance in Sodipodi. You can use the 128x128 size many
> artists use. Do keep in mind the icon will have to be exported to the 16x16 size too. You
> already know how many objects and sub-objects an icon can have... Do not start to paint
> landscapes full of details. Use the same simple objects you drew before, KISS...
> 
> Export the icon as 16x16, 22x22, 32x32 and 128x128 png icons. Do you have Visual Consistency?
> You can not leave scaling to very small sizes to applications, since every pixel counts at small
> sizes. You can hand-optimize the 16 and 22 icons with the GIMP, as you did before.
>    Now you will have 3 images that matter: a svg vector icon, and 16x16 and 22x22 png icons.
> With the svg icon the bigger sizes can be rendered.
> 
> 
> 
> 
> 
> 
> 
> 
> !!!General tips
> Design your icons to match the look of those icons in KDE which already do exist. KDE uses the
> Crystal SVG icon set originated by Everaldo, take a good look at it!
> 
> Visual appearance: KDE-icons look clear, sharp, clean and crisp. They are easy to recognize --
> even those tiny pixmaps which measure 16x16 pixels.
> 
> [
> All KDE-icons are surrounded by a black line, except when it affects the "readability" of the
> image too much. Don't use antialiasing outside this line. Don't use the alpha channel at all for
> icons. Shadows should be black.
> ]
> [
> The larger the icons get the more realistic they should become. They still focus on certain
> colors though: For <http://artist.kde.org/colordepth.html>locolor-icons you should use colors
> from the <http://artist.kde.org/colordepth.html>locolor-palette only. Try to prefer shades of
> colours of the locolor-palette for the <http://artist.kde.org/colordepth.html>hicolor-versions
> of your icons.
> ]
> 
> Use icon elements consistently.
> [
> There are templates avaiable for folder-, package-, viewer-, mimetype-icons and more ...
> ]
> The lightsource should be in the upper left corner.
> Use appropriate concise metaphors that are international and can be understood in most
> countries/cultures.
> Two different things shouldn't be represented by the same icon.
> All icons should be easy to recognize by color-blind people.
> 
> 5% to 8% (depending on the study you quote) of the men and 0.5% of the women
> of the world are born colorblind. Please have a look at this URL for more detailed information
> on this topic:
> 
> "Effective Color Contrast  -- Designing for People with Partial Sight and Color Deficiencies" by
> Aries Arditi, Ph.D
> Don't use text in icons
> Do not use any work that is not original. That means if you didn't draw it, we can't use it.
> Don't take from other desktop environments (Gnome, Windows, MacOS) and don't take from the WWW.
> Try to be original instead.
> Don't be insulting or pornographic.
> 
> 
> Toolbar- and application-icons
> 
> In KDE there are two general types of icons. There exist special guidelines for each of these:
> 
> Toolbar-icons are very often concrete icons: they are pictures or close representations of the
> operations which they represent. Toolbar-icons are generally much more being used than
> application-icons. So one needs to find them and recognize the purpose they resemble fast.
> Therefore they are usually more symbolic and simple than applicaton-icons to improve usability.
> Toolbar-icons are tools one just wants to use. Making them too detailed, color- and beautiful
> would decrease usability a lot.
> 
> Application-icons": being used to start applications, to resemble folders, mimetypes and
> devices.
> 
> On the other side many application-icons are abstract icons: they are are abstract designs that
> may have only a superficial or simplified representation of the operation. Some bear no relation
> to the functionality at all. Instead application-icons try to be much more unique, original and
> beautiful -- they are the brand of the application and are used to "advertise" the application
> (Think of the CorelDraw icon e.g. -- If you wouldn't know what this icon is about you would
> never guess that a vector-graphic-application starts once you click on it).
> 
> 
> 
> 
> In addition to the basic iconstyleguides which are valid for all icons there are some special
> guidelines for creating application-icons:
> 
> Application-icons are used to start applications, to resemble mimetypes ("documents"),
> structures of the filesystem ("folders, links, ...") and devices.
> 
> 
> 
> 
> 
> [
> In KDE different sizes and <http://artist.kde.org/colordepth.html>colordepths of
> application-icons are implemented as iconthemes. There are four types of default-iconthemes
> ("incarnations") which are in accordance with this styleguide:
> A P P L I C A T I O N - I C O N S
> Dimension / color-depth Example icons Comment
> 16x16 (<http://artist.kde.org/colordepth.html>locolor) required
> 32x32 (locolor) required
> 32x32 (<http://artist.kde.org/colordepth.html>hicolor) recommended
> 48x48 (hicolor) optional
> ]
> 
> [
> Recommendation for the kde-artist-team:
> We should support all of these incarnations! Please always start with the locolor-incarnations.
> Then scale the 32x32-locolor-incarnation up to 44x44 and 'repair' your icon to make it look
> sharp, clean and colorful again. You may also add some detail (but not too much!). Finally add a
> blank 2-pixel-border on each side. When the 48x48-incarnation is done scale it down to 32x32 and
> 'repair' it again or create the 32x32-hicolor-version from the 32x32-locolor-version directly.
> ]
> 
> [
> Make sure that all four incarnations of your icon have a
> <http://artist.kde.org/consistency.html>consistent look. This may require iterative work between
> them.
> <http://artist.kde.org/guidelines.html><http://artist.kde.org/toolbar.html>
> maintained by <mailto:luci@sh.ground.cz>luci<mailto:luci[at]sh.ground.cz>luci.
> ]
> 
> 
> 
> 
> 
> 
> [
> 
> 
> Colordepth
> Black/white-icons
> 
> These icons will be used by LCD/Monochrome-displays and by visually impaired people. There will
> be special <http://artist.kde.org/bw.html>guidelines for these kind of icons.
> 
> Locolor-icons
> 
> The low-color icons are provided for compatibility with very old video hardware which puts
> limitations on the number of the colors the desktop one can use safely. Of course KDE would
> dither hicolor-icons on 256-color-displays. But certain combinations of icons/wallpaper don't
> give acceptable results. Therefore KDE provides a set of locolor-icons for this case.
> To create the locolor-version ("incarnation") of your icon you have to choose colors of the
> locolor-palette only.
> 
> Hicolor-icons
> 
> When creating the hicolor-incarnation of your icon please try to be consistent with the
> locolor-version of your icon.
> The colors which you use should still stay quite close to the locolor-palette. This means that
> the gradients which you might use should start at the colors of the Locolor-Palette and end
> there where possible e.g..
> 
> Locolor-icon-palette
> 
> Each table contains 40 unique colours. There are 6*7 = 42 cells with black appearing 3 times.
> There also exists a ready made <http://artist.kde.org/KDE> palette for The Gimp.
> 
> 
> 
> RGB Values (HEX)
> 
> #303030 #585858 #808080 #a0a0a0 #c0c0c0 #dcdcdc
> #400000 #004000 #000040 #404000 #004040 #400040
> #800000 #008000 #000080 #808000 #008080 #800080
> #c00000 #00c000 #8080ff #c0c000 #00c0c0 #c000c0
> #ff0000 #00ff00 #0000ff #ffff00 #00ffff #ff00ff
> #ffc0c0 #c0ffc0 #c0c0ff #ffffc0 #c0ffff #ffc0ff
> #ff8000 #c05800 #ffa858 #ffdca8 #ffffff #000000
> 
> RGB Values (DEC values)
> 48 48 48
> 88 88 88
> 128 128 128
> 160 160 160
> 192 192 192
> 220 220 220
> 64 0 0
> 0 64 0
> 0 0 64
> 64 64 0
> 0 64 64
> 64 0 64
> 128 0 0
> 0 128 0
> 0 0 128
> 128 128 0
> 0 128 128
> 128 0 128
> 192 0 0
> 0 192 0
> 128 128 255
> 192 192 0
> 0 192 192
> 192 0 192
> 255 0 0
> 0 255 0
> 0 0 255
> 255 255 0
> 0 255 255
> 255 0 255
> 255 192 192
> 192 255 192
> 192 192 255
> 255 255 192
> 192 255 255
> 255 192 255
> 255 128 0
> 192 88 0
> 255 168 88
> 255 220 168
> 255 255 255
> 0 0 0
> <http://artist.kde.org/toolbar.html><http://artist.kde.org/consistency.html>
> maintained by <mailto:luci@sh.ground.cz>luci<mailto:luci[at]sh.ground.cz>luci.
> 
> ]
> 
> 
> 
> Consistency Please try to stay consistent throughout the whole K Desktop Environment:
> between toolbar- and application-icons
> between different incarnations of icons
> concerning icon elements
> 
> Consistency among incarnations
> 
> [
> For KDE we need to have every icon in different sizes and colordepths ("incarnations"). Larger
> incarnations of an icon should of course show more detail than the smaller version. But don't
> add too much detail: we have to make sure that the user won't be irritated by icons which look
> very different and represent actually the same thing. So all incarnations of an icon have still
> to look very similar.
> 
> Therefore larger versions of an icon are usually made from smaller incarnations. For the artist
> this isn't just a matter of scaling the icon up (or down). Everytime an icon is being scaled the
> artist has to 'repair' his icon. In many cases this means that the icon needs to be recreated
> completely. Of course it makes very much sense to use the scaled icon as a reference/template:
> 
> While you recreate your icon you have to make sure that outside your lines there are no
> semi-transparent pixels left. The lines themselves should look black, straight and sharp again.
> To get a cleaner design it's recommended to redo the gradients, too.
> Icon-templates
> 
> ]
> 
> 
> Use icon elements consistently if you create a new icon. If a shape for an icon element already
> does exist, don't change it.
> [
> There are templates available for packages, folders, pencils, viewers and many other icon
> elements.
> ]
> 
> 
> 
> 
> 
> 
> Storing & submitting icons
> 
> !!!Vectors and pixels
> The Crystal SVG icon set is a vector icon set. The icons are drawn in vector drawing programs
> and saved as .svg or .svgz. Many artists work at the 128x128 size. SVG is a evolving standard,
> for the moment the svg sources are exported to png icons in the sizes 16x16, 22x22, 32x32,
> 48x48, 64x64 and 128x128. As seen in the Icon Boot Camp, the smallest icons need repair. Always
> send in the svg and the 16x16 and 22x22 png icons. The bigger pngs can be rendered with scripts.
> 
> Since svg is an evolving standard, keep all sources you have. No program has svg implemented
> fully and correctly. For instance, if you work in Illustrator, also keep your .ai files. May be
> later svgs can be made out of them with a higher quality. Sending in the .ai files too would be
> welcomed!
> 
> 
> !!!Naming convention
> 
> The Crystal svg icons follow the crsc-mime-kate.svgz naming convention. The first part crsc-
> says it is a Crystal source. The second part of the filename contains the purpose of the icon:
> device: The icon resembles a device
> filesys: it symbolizes a certain part of the filestructure (folders, links, etc. ...)
> mime: a document belonging to a certain mimetype is being resembled by this icon
> app: clicking the icon starts an application
> action: a toolbar-icon
> The actual name is the last part of the filename. It can be followed by a "_" and the state of
> the icon. The extension .svgz makes clear it is a compressed .svg file.
> 
> The Crystal png icons follow the cr16-mime-kate.png naming convention. Here the cr16 says it is
> a Crystal icon size 16x16. Likewise there are cr22, cr32, cr48, cr64 and cr128 icons.
> 
> 
> 
> [
> All icons should be saved using the PNG-file-format.
> Choosing the right filename
> 
> 1.) The first part of the name gives informations about the colordepth (lo=LoColor or
> hi=HiColor) and the size (s,m,l) of the respective icon. For application-icons one gets:
> 16x16 Locolor: lo16
> 32x32 LoColor: lo32
> 32x32 HiColor: hi32
> 48x48 HiColor: hi48
> For toolbar-icons you'll get:
> 16x16 Locolor: lo16
> 22x22 HiColor: hi22
> 32x32 HiColor: hi32
> Black & White-icons are indicated using "bw".
> 
> 
> 
> 2.) The second part of the filename contains the purpose of the icon:
> device: The icon resembles a device
> filesys: it symbolizes a certain part of the filestructure (folders, links, etc. ...)
> mime: a document belonging to a certain mimetype is being resembled by this icon
> app: clicking the icon starts an application
> action: a toolbar-icon
> 
> 3.) The actual name is the last part of the filename. It can be followed by a "_" and the state
> of the icon
> 
> 
> 
> 
> Examples:
> hi48-device-cdrom_mount.png
> lo32-app-kicker.png
> lo16-mime-html.png
> hi32-action-editcut.png
> ]
> 
> Submitting your icon
> 
> Before you submit your icon make sure that your icon is compliant with this Icon-Styleguide. By
> submitting your icon to   icons --[at]-- kde --[dot]-- org   you agree that the kde-artist-team
> may use your icon as a part of a product of the kde-project under the respective free license of
> the belonging application.
> 
> You can also send your icon to   kde-artists --[at]-- kde --[dot]-- org  . This way you get
> feedback from the kde-artists community.
> 
> After you have committed your icon to icons@kde.org the icon-core-team will decide wether your
> icon matches the style-guides and our quality-expectations. In any case we will tell you within
> three days what will happen to your icon (If you should get no answer please contact us!). If
> there are still issues we will ask preferably you to fix them. But you should be aware of the
> fact that it might be possible that somebody else might apply changes to your icon as a part of
> the development-process. If everything goes well then your icon should be part of the
> KDE-CVS-tree within a week.
> 
> 
> 
> 
> [
> Styleguide
> Black & White -Icons
> 
> These icons will be used by LCD/Monochrome-displays and probably by visually impaired people.
> Guidelines
> 
> Because of the very special purpose of these icons they also need special guidelines:
> Black & White-Icons should be very symbolic and they should have shapes which are easy to
> recognize.
> Good contrasts: they should consist of areas which are filled black and white (not just black
> lines). Eventually you can also use black-white -patterns.
> These icons should be mostly 2-dimensional
> Examples
> <http://artist.kde.org/storing.html>
> maintained by <mailto:luci@sh.ground.cz>luci<mailto:luci[at]sh.ground.cz>luci.
> ]
> 
> 
> 
> 
>  - already in the wiki: References
> 
>  more:
> 
>  (wiki laylout)
> SVG:
> [http://www.w3.org/Graphics/SVG/|w3.org]
> [http://xml.apache.org/batik/svgviewer.html|viewer]
> [http://www.mozilla.org/projects/svg/|mozilla]
> [http://www.w3.org/Graphics/SVG/SVG-Implementations.htm8|links at w3]
> 
> 
> [http://www.adobe.com/svg/viewer/install/main.html|adobe viewer]
> 
> [http://www.smartgraphics.com/Viewer_prod_info.shtml|viewer]
> [http://www.ionicsoft.com/demo/svg.jsp|ionicosoft]
> 
> 
> 
> 
> Resources
> Software & Snapshots
> 
> 
> Software
> [http://www.sodipodi.com/|sodipodi] - vector drawing program, open source
> [http://www.koffice.org/karbon/|karbon] - vector drawing program, open source
> [http://www.adobe.com/products/illustrator/main.html|illustrator] - vector drawing program
> [http://www.gimp.org/|The Gimp] -- recommended for pixel images.
> [http://www.imagemagick.org/|Image Magick] --can be used to convert files, the GIMP has better
> compression. At the moment imagemagick really has magical output from svg files - do not use it
> for svg.
> 
> 
> 
> 
> The svg2png4kde script renders svg to png, with the correct file names:
> [http://www.kde-look.org/content/show.php?content=10055|svg2png4kde]
> 
> [
> Snapshots
> 
> Soon there will be packages available here which will include all icons per CVS-module.
> <http://artist.kde.org/references.html><http://artist.kde.org/credits.html>
> maintained by <mailto:luci@sh.ground.cz>luci<mailto:luci[at]sh.ground.cz>luci.
> ]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > _______________________________________________
> kde-artists mailing list
> kde-artists@mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-artists
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
_______________________________________________
kde-artists mailing list
kde-artists@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-artists
[prev in list] [next in list] [prev in thread] [next in thread]