Re: Dia 0.88.1: Problems with exporting to xfig

[Cyrille Chepelov <chepelov calixo net>]

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... ).

        -- Cyrille

-- 
Grumpf.