Subject: GR_Image is raster specific
From: Justin Bradford (justin@ukans.edu)
Date: Thu Mar 09 2000 - 17:02:52 CST
While looking through the image related code, I've noticed that the
text/fmt code (FG_Graphic) is supposed to handle both raster and vector
graphics. However, it returns a GR_Image when generateImage is called.
One would figure that GR_Image would be a generic class for both raster
and vector types (ie. GR_ImageRaster would currently exist). However, the
implementation of GR_Image over in af/gr is decidedly raster specific.
It has load/save PNG virtual functions and the platform specific
implementations are for raster data (generating things such as DIBs or
rgba arrays).
Furthermore, over in the GR_Graphics classes, createNewImage and drawImage
(which deal with GR_Images) are expecting raster images.
A (simple) SVG implementation is really quite easy, and completely XP (by
just drawing with the conventional GR_Graphics classes). Someday, we would
want to extend GR_Graphics with things like curves, alpha channels,
gradients, etc, but the SVG implementation could always draw on it, and
stay XP code.
However, one cannot drop in a vector image type with the current
framework. The wp code expects GR_Image to be generic, but the graphics
code thinks GR_Images are raster.
My recommendations:
change
GR_Graphics::createNewImage(char* name, UT_ByteBuf* PNG_data, sint32
width, sint32 height)
to
(char* name, GR_ImageType vector_or_raster_or..., UT_ByteBuf*
generic_image_data, sint32, sint32)
then the actual function, rather than creating a new GR_Image
makes a GR_ImageRaster or GR_ImageVector
and calls createFromPNG or createFromSVG (As appropriate)
This also implies changing GR_Image to remove the load/savePNG
functions. Otherwise they stay the same, but a new class
GR_ImageRaster is made, subclassing GR_Image,
(and corresponding GR_StretchableImage/Raster)
The existing platform specific GR_Unix/Win32/BeOS/QNX/MacOS/Image classes
are changed to subclass this Raster base class. Ideally, they would
renamed to include Raster in their names, too, but it's not really
important (since there will be no platform specific vector image).
And of course, we create an XP GR_ImageVector subclassing
GR_StretchableImage which implements a useful subset of SVG.
And finally, GR_Graphics::drawImage(GR_Image, xdest, ydest) is changed to
either:
1)
if (image->type() == RASTER) {
// current code
} else {
image->render(this, xdest, ydest);
}
or
2)
image->render(this, xdest, ydest);
// and the code currently in platform specific drawImage gets moved into
// the platform specific GR_Image class (might require some friending of
// the classes to provide access to things like underlying DCs).
As for the file format, I was thinking we should use the same design as
raster images: have a separate data item, but in that data item, we should
the SVG code. I think it would work better if we could pass the SVG XML
directly to the GR_ImageVector and let it parse the XML itself (so we can
have SVG input come from multiple entry points (paste, import, and load).
Of course, this means we have to sneak the SVG code by expat so we can
save it as a normal data item. Or maybe we can pass control to the
ImageVector expat handlers somehow? Possibly using the special namespace
stuff in expat? I'm not sure how we do this yet.
Any thoughts?
Justin
This archive was generated by hypermail 2b25 : Thu Mar 09 2000 - 17:03:06 CST