Hi all, as you might be aware of, I have recently been working on "Icon-O-Matic", the icon editor for Haiku, along with a vector icon design / document structure and corresponding file format. I have put a preview release of Icon-O-Matic, along with a couple of self-made sample icons at this location: <http://www.yellowbites.com/stuff/icons.zip> If you are interested in helping with icon artwork for Haiku, please have a look. :-) Best regards, -Stephan To save you some hassle, here is what I wrote in the Readme: ---------------------------------------------------------------------- Icon-O-Matic Readme Hi, thanks for taking the time to read this and for your interest in Icon-O-Matic. Introduction: We Haiku developers agree on the fact that Haiku cannot be officially released with the original BeOS R5 icons. For this reason, all icons within Haiku need to be original artwork. Since we have to do this work anyways, we might as well switch to vector icons now. At least we should be able to design the icons in a vector format, so that we don't have to do it all again when we do switch to vector icons. However, as things progress, I am confident that we can use vector icons in R1 without the associated drawbacks. The drawbacks are that vector icons usually don't look crisp at small sizes (16 x 16), and that they need too much storage space. I have come up with a rendering engine (based on Anti-Grain Geometry <www.antigrain.com>) and a storage format that try to work around these problems. Storage Format: Haiku Icon-O-Matic supports currently two storage formats: A "native" BMessage based format that stores *all* attributes of the icon document without worries (and you should always have a backup of your icons in this format). Then there is the "flat" format, which is the storage format that I came up with to save an icon in as little space as possible. It is not yet feature complete, but promises already to use very little space. BeOS native icons are bitmaps, a large (32x32) and a small (16x16) one. They use 8 bits per pixel for storing indices into the BeOS system palette. Therefor they use 1024 bytes for the large icon and 256 bytes for the small one. So BeOS totals at fixed 1256 bytes for an icon. As you can see in the examples folder, the biggest icon I designed uses only 543 bytes. Note: It is important to have small icons, because the responsiveness of the Tracker and Deskbar will depend on it. If the icon attribute fits within a files "inode", there doesn't have to be a second disk access per displayed file with unique icon. Crisp Display: The new vector icons support a number of features that are designed to improve crisp display: 1) Rendering is performed in linear gamma RGB space to elliminate false colors at anti-aliased pixels. 2) Shapes support "level of detail". Each shape has two attributes, minimum visibility scale and maximum visibility scale. If the global scale of the icon falls below "minimum scale", then the shape is not rendered, likewise with maximum scale. This feature allows in effect to have multiple appearances in one icon which the renderer chooses depending on the global icon scale. 3) Shapes support "rounding", that is, vector coordinates will snap to whole pixels if rounding is turned on. This feature can be weird with regard to shape transformers, and needs to be used with care. The snapping is done after any transformations, so shapes will snap to pixels regardless of global icon scale. Of course, this makes the shapes appear more crisp. 4) Icons are rendered in a single pass, removing the problems of "seems" at adjacent shapes. See "Tipps and Tricks" for more on this. Icons documents: I chose to design the icon structure in a way that allows to have powerful features while keeping the icon size small. However, for some types of icons, the way in which they are designed in Icon-O-Matic will feel cumbersome. The purspose of this test release is also to get feedback on how this could be improved. An icon is made up of three parts: Styles, Paths and Shapes. A Style is either a solid color or a color gradient. A path is a sequence of Bezier curves and/or straight lines. Styles and paths are global to the icon. Then the shapes reference them. So the same style could be used by multiple shapes. Each shape has exactly one style assigned to it. For paths, it is a bit different, each shape can have any selection of the available paths assigned to it. Then each shape can have an optional list of Transformers. A transformer takes vector data and "transforms" it in some unique way. For example, there is a Stroke transformer which takes a vector path, and produces another vector path which formes a "stroke" around the original path. The output of one transformer is piped into the next transformer. Example: Suppose you want a white circle with a black outline. You could start by creating a new path which is a circle (no sorry, you have to draw it yourself, there is no circle tool in Icon-O-Matic yet). Then you create two styles, make them white and black. Now you can create the first shape. When a shape is selected (in the shape list view), the path and the style list view display check marks in front of the paths/styles so that you can assign them to the selected shape. For this shape, you would mark the circle path and the white style. Now create the second shape. While the shape is selected, add a Stroke transformer in the transformer list view. Now you can assign the black style and (again) the circle path. Whatever change you do to the circle path, it will reflect in both shapes. You will have noticed that whatever object you have selected, its properties will be displayed in the Property list view. There you can rename the object, and depending on the type, adjust additional properties, like the width of the Stroke transformer, or wether the path is closed and so on. That's basically it, that's how you built up icons. Over time, the comfort will be improved, I know it's very basic right now. Please don't hesitate to write feedback with your ideas and complaints though! Also keep in mind that Icon-O-Matic is not stress tested, save early, save often. When it crashes, please send me the stack crawl! Additionally, many menus are incomplete or pretend to support something when they don't. No need to report this, though. Tipps & Tricks: Icons support the alpha channel in colors and gradients. But because of the single pass rendering, it is not supported to layer a semi-transparent shape on top of other shapes. The icon is rendered as if it was flat! This is the lesser of two evils in my opinion, but switching from "single pass compound shape" rendering to "traditional multi pass" (bottom to top) rendering is trivial. So if enough people complain, I can change it easily. But for the time being, please bear with me, it really pays off with regards to the crisp icon look. If you want stuff like self-shadowing or highlights, be creative with fake transparency, take my "App Icon" as an example. To get the smallest possible icon size, use the "pixel snapping" feature from the Settings menu when you design vector paths. Try to reuse a single path in mutiple shapes, note that you can transform a shape to whereever you want, independent of the path. It will also allow you to make changes to multiple shapes at once, only by adjusting a single path. Icons are designed at a "native" resolution of 64x64 pixels. To make shapes appear sharp at lower resolutions, optimize for the 32x32 and 16x16 size by placing the more important shapes at the 32x32 or 16x16 coordinate grid. There is currently no helpful snapping for this purpose, but you can keep an eye on the smaller icon previews to get it right. Have fun and best regards, -Stephan Feedback: <superstippi@xxxxxx>