Re: Properties for the GR_Graphics?

On Tue, 2007-05-01 at 20:33 -0400, Leonard Rosenthol wrote:
> I think that idea of having properties associated with drawing objects
> is a VERY good thing - and you are right, there are a variety of
> things that can be done with them in smart graphics systems.
>
> However, you need more than a single "char**" to store them. I would
> recommend using a HashMap-type datastructure that can store name/value
> pairs - since that's the most flexible and also most compatible to
> systems like SVG and PDF.
>

Hi Leonard,
          How nice to hear from you :-)

Great minds think alike. The interface is char **, ie an array of char
*'s so we can hold a variety of name-value pairs terminated by a NULL.

eg

char ** properties={"hyperlink","http://www.abiwource.com",
"bookmark","HAWYF",
"page-transition","flip-vertical",
NULL, NULL}

Cheers

Martin

> Leonard
>
> On 5/1/07, msevior@physics.unimelb.edu.au
> <msevior@physics.unimelb.edu.au> wrote:
>
> Hi folks,
> I propose an extension to the GR_Graphics API. I
> suggest we add a
> method:
>
> virtual void GR_Graphics::setPropeties(const char **
> szProperties)
>
> We can use this to set non-displayable properties of text.
> Things like
> bookmarks, hyperlinks, animations or metadata.
>
> Mordern graphics formats like pdf and svg allow these very
> useful
> properties but we have no hooks to enable any graphics backend
> to generate
> them.
>
> With properties, we could for instance set a hyperlink
> property during a
> call to fp_HyperlinkRun::draw() or fp_BookmarkRun::draw().
>
> I presentation program could use properties to describe a
> slide transition
> or animation that would be invisible in the compostion phase.
>
> Making the method virtual means that the graphics
> implementation used for
> compostion could just safely ignore the method, while classes
> used during
> printing could use them to generate these additional features.
>
> Opinions folks?
>
> Cheers
>
> Martin
>
>
>
Received on Wed May 2 04:02:55 2007