Here are some of the more ambitious projects for the development of Skencil: Color Management (Gamma Correction) =================================== Implementing this might be quite complicated. First of all, colors should be represeneted in a device independent manner. SKColor objects are currently simply RGB-triples. These could be considered device independent only for an ideal device with a gamma value of 1.0. The internal color representation should use a CIE based color model. Color managment comes in in various places: - drawing vector primitives in the window. color objects should be mapped to device colors on the fly (maybe via a lookup table or using some caching techniques) - drawing bitmap images. This is not trivial, since some images might already be converted to CRT device colors, while others may not. Even though some formats may contain information about this, it should be ultimately up to the user to specify whether and how color correction should be applied to a given image. - Printing/EPS. We should probably assume that the printer or whoever interprets the data does its own color correction, so we should use device independent colors there. - importing from other vector formats. Whether any color conversion has to be done depends on the particular format to be imported. XFig files for instance have device dependent color specifications and should be converted. The user should be able to specify the gamma value used for conversion independently from the gamma value used for the display in sketch. - exporting to other formats (vector and bitmap). Again, sketch's behaviour depends on the format involved, so the same considerations as for importing apply. Adding color correction affects sketch documents stored with the current color representation. In particular gradients and blendgroups that are recomputed after loading would be different, because currently color interpolations are done in RGB-space. With color management they would probably be done in the device independend color space, but that could probably be optional. A complete solution for would require support from X (for the display) and from Linux or rather the printing subsystem (for printing). Support For Plugin Modules/Objects ================================== (the basic functionality is already implemented) Plugin objects -------------- Plugin objects should be compound objects derived from a special class. To allow saving and loading of these objects even when the plugin is not installed, the plugin object should save all its components like a group and put all plugin specific information into the constructor. This could be done like this: . . . object('ClassName', param1, param2, ..., key1 = arg1, ...) . . . endobject() . . . If the object type ClassName is not known, this object is treated like an ordinary group. Actually, this could be a special object class that behaves like a group from the user's point of view but stores the plugin specific information. That way it could be saved like a plugin again, if it is not changed (i.e. ungrouped or otherwise edited. Other plugins should be treated in a manner that allows sketch to simulate them as much as possible if the plugin is not installed. Ideally, the ClassName has to be unique. There should be a naming convention to facilitate this (maybe including a registry for `official' plugins). Also, any name conflicts should be handled as gracefully as possible with the object treated like an unknown plugin if errors occur. Some ideas for plugins: - A Graph object (a la GNUPlot, etc). This could be very complex... - A Frame object (with subobjects for the corners and the sides that behaves in a special way when the frame is resized) - Additional patterns (they would have to be converted to a builtin pattern if the plugin is not available) - Additional edit commands (these don't affect load/save) - Plug-ins for new file formats (XFig, Tgif, ...) If possible there should be a `lazy' import mechanism for plugins to reduce memory demand. Export filters -------------- They could be implemented in three ways: 1. As classes implementing the same interface as SKSaver. This allows to use the capabilities of the target format to their full potential. Advanced features like blend groups or even gradient fills and compound objects could be preserved if the format supports them. The disadvantage of this approach is that SKSaver's interface is closely related to the internal document structure (and to some degree to the SK-format). Every time the structure changes, the interface changes too. 2. As graphics devices. The advantage of this approach is that the interface of the graphics devices changes only infrequently. The filters won't have to be updated as frequently as for the other model. A disadvantage is that the graphics device is relatively low level. Graphics devices don't know about compound objects (like layers or groups) so this information would be lost. 3. The filter traverses the object hierarchy on its own. This is the most flexible approach, though it would require that the filter knows a lot about the internal structure of the document. This is not really as bad as it seems at a first glance. A simple implementation treats all compound objects, easily identified because their is_Compound attribute is true, like groups and rectangles (with sharp or round corners) and ellipses like bezier objects (just test whether an objects is_curve attribute is true and use its AsBezier method). The best approach would probably be to use the third model for complex formats and the second for very simple formats (simple in their structure, not necessarily their graphics capabilities). Import/Export Filters --------------------- Formats that should be supported by filters included in the standard distribution: Format Method Implemented ------ ------ ----------- XFig (+) 3 read (incomplete) Tgif (+) 3 Adobe Illustrator 3 read/write (both incomplete) PostScript 2 write (read via pstoedit) Bitmap files (*) 2 write (very experimental) LaTeX (%) 2 less important and perhaps impossible (because of lack of documentation): StarOffice (#) 3 Applixware (#) 3 CorelDraw (W#) 3 WindowsMetafile (W+) 2 (might be read as a bitmap image with PIL) (+) These formats don't know bezier curves. (Windows Metafiles for W32 might know, though) (*) Bitmap files could be created via PostScript/Ghostscript (%) Might be difficult because some of those formats are very limited (W) MS-Windows (#) Are these formats documented anywhere? Some formats don't have bezier curves. If they have other splines, bezier curves should (optionally) be approximated by those splines. If they don't have splines at all curves should be approximated by polygons. Also exporting MaskGroups and complex fill patterns (e.g. gradients) can be a problem since some formats are very simple and have no clipping capabilities or don't have the appropriate fill styles. Even exporting dash patterns and arrow heads is not trivial, since some formats only have a limited predefined set of such patterns and arrows (XFig and Tgif for example). Special Effects =============== Calligraphic Effects -------------------- The user should be able to specify a non circular pen shape. Elliptical or rectangular pens would be desirable. This could be implemented by computing a polygon for a given curve and resolution and filling it with the line pattern. The polygon should be computed on the fly by the graphics device (with caching if that is too slow). An advanced feature would allow the pen shape to vary along the curve (it might be larger at one end, etc.). Transparency / Alpha Channel ---------------------------- Does anyone know how to do this efficiently in X and PostScript? More Shading Patterns --------------------- Have a look at the capabilities of PostScript Level 3. Especially the Gouraud shading, Coons-patches and tensor product patch meshes.