Re: Dia 0.88.1: Problems with exporting to xfig

[Lars Clausen <lrclause cs uiuc edu>]

On Tue, 12 Jun 2001, Cyrille Chepelov wrote:

> Le mar, jun 12, 2001, à 12:47:18 -0500, Lars Clausen a écrit:
>
> > > Both these functions pointers would be members added at the end of
> > > struct RendererOps, and would be totally optional (ie, diagramdata.c's
> > > routines will check for NULL members, and either repeatedly check, or
> > > fill the renderer->ops with stubs. Hmmm. Fill with stubs, that makes
> > > the code easier, costs as much cycles and one less prediction entry).
> >
> > Sounds like a good implementation plan.  Only the FEATURE and SHAPE
> > groups don't really solve the problem, as all you can really do at this
> > level is group.
>
> FEATURE is to say something like "these four segments and these four arcs
> are really a rounded rectangle, here's the corresponding Rectangle and
> corner radius (ie, gpoint hints in fact is a pointer to struct {Rectangle
> rect; real corner_radius). SHAPE is an alias for OBJECT (dunno if that
> specialisation is really necessary).
>
> > Somebody (I forget who) suggested having some more complex shapes
> > (arrows, rounded rectangles etc) have their own rendering function, but
> > have a default that uses the more primitive functions.  Of course, we
> > only want a limited amount of these, or the renderer structure becomes
> > rather large, but at least having them for the basic shapes would be
> > good.
>
> OTOH, we could have have FEATURE_ARROW etc. Both options are open (I'd
> think have renderers give NULL ops pointers for optional functions, and
> have something in diagramdata fill in stubs & helpers, so we don't need
> to test for the presence of this or that function, could be a very nice
> simplification, however. renderer->ops->predraw_string() is an obvious
> candidate... ).

A third idea I came up with for this:  Have the renderer only define the
most basic shapes as fixed function pointers, and everything else
(rectangles, arrows, polylines, even complete shapes if the renderer wants)
be in a hashtable.  Then things like Visio or Kivio export can try to
retain more complex objects through a plug-in.

I really like having each shape (including the basic ones) be rendered by
its own function, rather than having to have special dispatch based on the
features.

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor
"I do not agree with a word that you say, but I    | Retainer of Sir Kegg
will defend to the death your right to say it."    |   of Westfield
    --Evelyn Beatrice Hall paraphrasing Voltaire   | Chaos Berserker of Khorne