Here are some of the more ambitious projects for the development of
Sketch:


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, ...)
<object1>
<object2>
.
.
.
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.

