Hi all,
I'm having a look through EMF+, which is the metafile type
corresponding to GDI+, to see what is in it that
would add SVG features not currently representable in EMF (vanilla
GDI). So far...
These would be worth having:
1. Objects with colors that are RGB + Alpha. GDI uses only RGB and
mixing operators to
emulate opacity, the mixing operators are complex and I did not
implement 99% of that in
the present EMF input/output code.
2. Gradients. EMF has gradients, but the rectangular gradient record
is apparently toxic - I have yet
to find an application, including from Microsoft that can accept one.
The majority of programs
that write EMF files work around this by writing scads of tiny
rectangles to emulate the gradient.
(By majority I mean no programs, other than the ones I wrote, generate
EMF gradient records.)
Possibly the EMF+ gradients are not toxic so input/output of SVG
gradients can stay as gradients and
not have to be emulated.
3. Expanded hatch patterns (up from 7 in GDI [essentially] to 52).
4. Custom line caps.
It is not clear to me how many of the other features in GDI+ have SVG
equivalents. For instance:
5. Compound lines. GDI+ can draw a line with what is essentially a
row of pens of various widths. Define
a pen with a narrow stroke, space, wide stroke, space, narrow stroke,
and draw a rectangle, and the result is
a set of 3 nested rectangles, with a fat central stroke and thinner
strokes inside and outside of it. Can SVG
do this? I'm thinking one would have to import this in a loop, and
create the rectangles one by one with
the appropriate "sub" pen.
6. Clipping regions can be combined with XOR, UNION, INTERSECT and so
forth. However, I do not recall in the
present EMF output that clipping information is passed into the driver.
Rather I vaguely recall that it was applied many levels above and the
clipped shape is what is sent to the output driver. Other than for
clipping
there does not seem to be a way to create compound regions using these
operators. I don't think SVG has
these operators for general shapes either. Inkscape performs these
operations on paths, but just puts the
combined path in the SVG.
7. Graphics containers. Apparently the point of these is to provide a
way to segregate high cost
operations (like antialiasing) from low cost ones (a normal draw). So
on one screen set up different
containers and the quality sensitive ones are sent into the high cost
container, while everything else
goes into the lost container. For a Metafile this makes no sense, we
are not interested in real time performance,
and all objects should remain high quality.
8. Gradient curves. GDI+ does this by specifying an array of points
(the curve) and a corresponding array
of colors, and then some rules about how to interpolate colors. (Fill
is another story, that uses a brush
with a defined gradient.) I could not find an example of SVG stroking
a gradient curve like this, other than
by breaking it down into a series of separate line segments of slowly
varying color.
One thing that is definitely not a step in the right direction EMF to
EMF+, at least in terms of
dealing with the resulting metafile:
9. Remarkably few EMF+ objects and records have a fixed size. There
are so many "optional" and "variable"
fields that most objects and records cannot be represented with a
struct. There were some complex EMF records, as for image storage, that
were like this, but most EMF records had a fixed memory layout, so one
could
map a pointer in memory to a struct, and then just reference the values
in that record by field names. That rarely
works for EMF+ records.
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
