Home » Eclipse Projects » GEF » Generic Image Export
| Generic Image Export [message #203790] |
Mon, 28 November 2005 10:18  |
 Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Hi all,
I have thought about exporting GEF diagrams to "images" in several
formats in a generic and extensible way. I have implemented an
architecture that divides the whole thing into several plug ins and
would like to ask you gurus for comments on that. What follows is a
description of what I did/would like to do.
We have hacked in export support for the following formats:
- the two bitmap formats supported by SWT (JPEG and BMP)
- PDF export using itext (partially implemented)
- SVG export using batik (should be partially implemented)
Now I thought about polishing it all up and putting it on sourceforge.
We are using third-party software to generate PDF and SVG. Batik e.g.
is really a biggie so I would like to design something that allows you
to install only what you need, i.e. have the SVG export capability
separate from everything else and the PDF export capability separate
from everything else and so on, possibly in different plug ins.
Now, to export a GEF diagram you need to
a) load the model file
b) render it to the desired format and save it
It is impossible to implement loading the model in a generic way because
each model is different. So people who would like to use the export
plug in would have to give it something more universal. Eventually,
each model displayed in a graphical viewer is displayed as a figure, so
I thought I'd use that.
The figure can be told to paint itself, passing it a Graphics argument.
So by using SWTGraphics or writing other Graphics adapters, the
rendering to another format can be done transparently (not talking about
alpha channels here :)).
I thought it would be nice if the user was able to choose File >
Export..., select "Diagram Image" as the export engine and was presented
with a typical export wizard that allows choosing which files to export
into which target directory and so on.
So I came up with the following architecture: each client that wants to
contribute a model format to the export wizard, registers a
FigureProvider (suggestions for good names are especially welcome) at
the ImageExport plug in. Figure providers know how to load the model,
create a GraphicalViewer, set an EditpartFactory and so on and finally
get the root figure. Figure providers register the file types they
understand and get asked by the export wizard to provide a figure for a
model file.
Then there are ImageExporters that know how to render a Figure to the
format they export to and save the result to a file. They also register
at the ImageExport plug in. When the user calls the image export
wizard, the user can choose one of the registered formats from a combo box.
I did all that to keep the plug in dependencies down to a minimum. Your
own editor that wants to contribute to the export wizard may provide a
FigureProvider and *optionally* depend on the ImageExport plug in. That
means that it will register at the ImageExport plug in if it is
installed and that nothing will happen if it is not installed.
The exporter plug ins depend on the ImageExport plug in. The user
chooses which formats he wants to be able to export to and installs
exactly the ones needed,
As soon as the ImageExport plug in is installed, the user may activate
the Export Image wizard.
Does that all seem to make sense to you? Comments, suggestions,
discussion, anything is welcome.
Regards, Thomas.
|
|
|
| Re: Generic Image Export [message #203809 is a reply to message #203790] |
Mon, 28 November 2005 13:27  |
Eclipse User |
|
|
|
Originally posted by: zx.us.ibm.com
You may also want to look at what GMF has for image export. I recall
them having export capability to a bunch of image formats (SVG,PNG,JPG,
etc...) as part of IBM's contribution.
Good work nonetheless ;)
Cheers,
~ Chris
|
|
|
| Re: Generic Image Export [message #203886 is a reply to message #203790] |
Mon, 28 November 2005 20:50 |
Felix L J Mayer
Messages: 202
Registered: July 2009 |
Senior Member |
|
|
Sounds good to me, can't wait to see some details...
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:438AD969.4000302@uni-kassel.de...
> Hi all,
>
> I have thought about exporting GEF diagrams to "images" in several
> formats in a generic and extensible way. I have implemented an
> architecture that divides the whole thing into several plug ins and
> would like to ask you gurus for comments on that. What follows is a
> description of what I did/would like to do.
>
> We have hacked in export support for the following formats:
> - the two bitmap formats supported by SWT (JPEG and BMP)
> - PDF export using itext (partially implemented)
> - SVG export using batik (should be partially implemented)
>
> Now I thought about polishing it all up and putting it on sourceforge.
> We are using third-party software to generate PDF and SVG. Batik e.g.
> is really a biggie so I would like to design something that allows you
> to install only what you need, i.e. have the SVG export capability
> separate from everything else and the PDF export capability separate
> from everything else and so on, possibly in different plug ins.
>
> Now, to export a GEF diagram you need to
> a) load the model file
> b) render it to the desired format and save it
>
> It is impossible to implement loading the model in a generic way because
> each model is different. So people who would like to use the export
> plug in would have to give it something more universal. Eventually,
> each model displayed in a graphical viewer is displayed as a figure, so
> I thought I'd use that.
>
> The figure can be told to paint itself, passing it a Graphics argument.
> So by using SWTGraphics or writing other Graphics adapters, the
> rendering to another format can be done transparently (not talking about
> alpha channels here :)).
>
> I thought it would be nice if the user was able to choose File >
> Export..., select "Diagram Image" as the export engine and was presented
> with a typical export wizard that allows choosing which files to export
> into which target directory and so on.
>
> So I came up with the following architecture: each client that wants to
> contribute a model format to the export wizard, registers a
> FigureProvider (suggestions for good names are especially welcome) at
> the ImageExport plug in. Figure providers know how to load the model,
> create a GraphicalViewer, set an EditpartFactory and so on and finally
> get the root figure. Figure providers register the file types they
> understand and get asked by the export wizard to provide a figure for a
> model file.
>
> Then there are ImageExporters that know how to render a Figure to the
> format they export to and save the result to a file. They also register
> at the ImageExport plug in. When the user calls the image export
> wizard, the user can choose one of the registered formats from a combo
> box.
>
> I did all that to keep the plug in dependencies down to a minimum. Your
> own editor that wants to contribute to the export wizard may provide a
> FigureProvider and *optionally* depend on the ImageExport plug in. That
> means that it will register at the ImageExport plug in if it is
> installed and that nothing will happen if it is not installed.
>
> The exporter plug ins depend on the ImageExport plug in. The user
> chooses which formats he wants to be able to export to and installs
> exactly the ones needed,
>
> As soon as the ImageExport plug in is installed, the user may activate
> the Export Image wizard.
>
> Does that all seem to make sense to you? Comments, suggestions,
> discussion, anything is welcome.
>
> Regards, Thomas.
|
|
| | | | | | |
Goto Forum:
Current Time: Thu Apr 25 18:49:53 GMT 2024
Powered by FUDForum. Page generated in 0.03538 seconds |
] 
Search
Help
Register
Login
Home
