Subject: Re: GR_Image is raster specific
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 15 2000 - 02:18:15 CST
Justin,
You're certainly correct that we'll eventually want to have ways to just
pass along encapsulated content without parsing it. I also agree that it's
very desirable to have a clean separation between the existing text
formatting code, and the new SVG or MathML formatting code.
All I meant to suggest was that as we contemplate adding in SVG and MathML
content to our file format, it may be worth taking advantage of the fact
that they each are likely to share the following characteristics with our
existing ABW content:
- they're represented as tags with attributes
- we're likely to want to make them editable via an undo mechanism
- plus which, they can optionally include spans of marked-up text, right?
Insofar as the existing attrprop and change history mechanisms already do a
very compact job of handling a number of these problems, my instincts
suggest that there may be more code worth sharing here.
It's a murky insight, and I certainly haven't convinced myself that this
stuff should *definitely* go in the existing piece table. However, I do
suspect that you may eventually need a lot of very similar mechanisms, and
thus we may want to think about sharing some or all of the relevant code.
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.
To put it another way, the *view-level* processing for the following three
types of content aren't likely to be similar at all:
- formatted text (ABW)
- vector graphics (SVG)
- equations (MathML)
They each require very different algorithms and formatting strategies.
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.
At 02:25 PM 3/14/00 -0600, Justin Bradford wrote:
>We should probably support undo/redo on (or through?) objects, anyway.
>Perhaps they should inherit from a base class with some basic interfaces
>(undo, redo, activate [editor?])-- but's veering off into component land.
Yeah, let's not go there now. I'm unconvinced that it's feasible to manage
undo states across component boundaries -- that sounds like a *lot* of
tricky API work -- but that discussion can certainly wait until we're ready
to make serious headway on it.
Just making the undo granularity work properly for text editing methods
seems to be enough of a challenge for us right now. ;-)
>As the SVG data needs to be fed to the Image/GraphicVector from a couple
>different points, it's just easier to handle the parsing in the Image and
>probably faster than allocating a bunch of intermediate piece table
>fragments.
Yes. It's definitely best to minimize the number of discrete parsers we
have for SVG data. One would be ideal.
In each case, it'll be an expat-driven parser, though, right? Unless I'm
missing something, standalone SVG content would be driven by the exact same
expat callbacks -- it's a pure special case of the more general parsing
problem when embedded in ABW files.
Does it make sense now why I was asking what the document-level data
structures for SVG content should be?
If this latest hypothesis is true, and if we want to use attrprop-like data
structures to store SVG content in editable form (my hypothesis from
yesterday), then we might just want to have both types of parsers --
embedded in ABW and standalone -- simply call a few new PD_Document methods
such as:
appendObject(PTO_SVGContainer, attribs);
appendObject(PTO_SVGItem, attribs);
appendObject(PTO_SVGItem, attribs);
appendObject(PTO_SVGItem, attribs);
appendObject(PTO_SVGItem, attribs);
or:
appendObject(PTO_MathContainer, attribs);
appendObject(PTO_MathItem, attribs);
appendObject(PTO_MathItem, attribs);
appendObject(PTO_MathItem, attribs);
appendObject(PTO_MathItem, attribs);
WARNING -- I'm not familiar enough with the content models for SVG and
MathML to know if this simple an approach would work. We very well might
need begin / append / end semantics instead.
>I think I'll implement it the way I was thinking initially, and then we
>can discuss changes from there.
By all means, if you've got a practical way to deal with the code factoring,
give it a whirl and see how it works. Working code beats email theorizing
any day of the week.
Paul
This archive was generated by hypermail 2b25 : Wed Mar 15 2000 - 02:12:44 CST