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