1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
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, ...)
<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.
|
