Subject: Re: GR_Image is raster specific
From: Justin Bradford (justin@ukans.edu)
Date: Wed Mar 15 2000 - 07:26:14 CST
> In short, I guess I think that SVG content *is* a lot more like ABW content
> than raster images, at least as far as the underlying document-level
> mechanisms are concerned. Raster images are just static blobs which can be
> stretched and cropped, and not much else.
I came at this problem from the vector image perspective. My design was
simply to extend the current image support to handle vector images (in the
form of SVG) with as little change to the surrounding code as possible.
And I have that part working. I've restructed all of the image code and
written support for vector types. My render does nothing (effectively) but
the infrastructure is there. I didn't rewrite the AbiWord importer yet,
but I did extend the image importer to support SVG types (in addition to
PNG), so I can load SVG and admire the colorful rectangles in my AbiWord
document.
I had to extend createNewImage in GR_Graphics, but that's really the only
change that effects routine use of the image class. One could, for
instance, replace the AbiWord splash screen with an SVG file just by
giving the createNewImage function it a buffer of SVG instead of PNG data.
> However, I do believe that the underlying *document-level* mechanisms for
> dealing with import/export and for undo-able editing can, and perhaps
> should, be rather similar.
>
> That's all. If this is a helpful suggestion, great. If not, that's OK.
I haven't really implemented the data side of the SVG/vector stuff yet. I
have the SVG in the image, but I'm not doing much with it yet. I was
concerned that using the piece table would interfere with the
encapsulation of the vector image interfaces, so I wanted to treat the SVG
like a binary blob which worked it's way straight to the GR_ImageVector
class (just like the PNG data does).
You're right, though; they're separate things, and while implementing the
interface side, I've started to think the data can be stored in the piece
table without affecting the use of the image. Specifically, I'm thinking
about the possibility of data items becoming strux-like, and refer to it
for the data access. I'll work on this as I finish my current
implementation. Regardless of where the SVG comes from, it will be parsed
into the piece table under a data item. The ImageVector class will just
keep track of the data item to read through the list of things to render.
And, if we keep a type id on the data item, I can simply some things
further, too.
Is the expat update ready to commit, yet? I'll need it soon.
Justin
This archive was generated by hypermail 2b25 : Wed Mar 15 2000 - 07:26:16 CST