Community
Participate
Working Groups
Allow to generate the SVG image corresponding to the currently edited workflow, from File > Export.
Apparently there's no native GEF to SVG export : https://bugs.eclipse.org/bugs/show_bug.cgi?id=175838 This is a longstanding bug in GEF, in part because contribution code was orignally GPL'ed (but this seems not to be the case anymore), and in part because it PARTLY depends on a GMF plugin, which HAS SVG export. In addition, here's some code from 2009/04 that does Draw2d -> AWT and then uses Batik's SVG exporter : http://www.developpez.net/forums/d717354/environnements-developpement/eclipse/eclipse-platform/export-diagramme-gef-image-svg/ Finally, to get some ideas for additional features in this scope, but not for code since it is incompatibly GPL'd, see the Image Export Plugin for Eclipse : http://www.se.eecs.uni-kassel.de/~thm/Projects/ImageExport/index.html
I just had a look around to check whether something changed since this bug was reported. It doesn't seem so. By the way, I found a very old project (2004) named Holongate (http://www.holongate.org/) which is released under EPL and has the same purpose. Every solution I came across seems to use GMF and Batik to export GEF diagrams to SVG. I'll try to do the same. It adds a GMF and a Batik dependency, but Batik (http://xmlgraphics.apache.org/batik/) is released under the Apache License and seems already included in the Eclipse repos, probably along with GMF (I already have it in my Eclipse without doing anything).
Well. Maybe I spoke too fast. The code example Marc provided above was using GMF, as I said. GMF provides SVG export features by converting draw2D graphics to Java2D (AWT), and then using Batik (which is only compatible with Java2D). The most "complex" (non-trivial, at least) part there is converting graphics from draw2D to AWT. Unfortunately, it seems the class in GMF converting from draw2D to Java2D is internal... It's GraphicsSVG, see here: http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.7/org.eclipse.gmf.runtime.draw2d.ui.render/awt/1.4.1/org/eclipse/gmf/runtime/draw2d/ui/render/awt/internal/svg/export/GraphicsSVG.java#GraphicsSVG So we end up with 3 naive, ugly solutions: * Copy the relevant code to JWT (GraphicsSVG and its dependencies) * Find a way to import these classes despite the fact they're internal * Use classes that actually provide this feature publicly. This would be DiagramSVGGenerator, I think (http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.7/org.eclipse.gmf.runtime.diagram.ui/render/1.4.1/org/eclipse/gmf/runtime/diagram/ui/render/clipboard/DiagramSVGGenerator.java?av=h#DiagramSVGGenerator). But obviously, this class is not intended to work directly with GEF; to instantiate a "DiagramSVGGenerator", one need a "DiagramEditPart", which is a GMF-specific class. We would thus need to instanciate a DiagramEditPart, and... Well, I guess you got the point: we'd better re-implement JWT from the ground up using GMF than do this. And we don't want to re-implement JWT ;) But there is more reasonable solutions, too: * Ask the GMF team to expose GraphicsSVG in its public API. This may take time, but maybe it will be OK for Juno? * Use Holongate (http://www.holongate.org/) for its bridge between Java2D and draw2D (http://www.holongate.org/holongate-2.0/doc/dev/api/org/eclipse/draw2d/J2DGraphics.html). With this, we could easily use Batik and then re-implement an equivalent of GraphicsSVG. I am currently trying to assert the feasibility right now, since this is an Eclipse 3.0 plugin...
OK, so Holongate includes some platform-dependent code (JNI/C). I guess it's no longer an option ;) To sum up: * Ask the GMF team to expose GraphicsSVG in its public API. This may take time, but maybe it will be OK for Juno? * OR mark this bug as WONTFIX.
Hi Yoann Thanks, your assessment is correct and in depth. It won't bite to ask the GMF team on their mailing list or bugzilla (as low priority), just have a look in the bugzilla / archives first whether it's already been asked. Regards, Marc
How extensive are the dependencies of GraphicsSVG? If they are somewhat limited I would vote for the obviously ugly but probably most pragmatic approach of duplicating them. As this is a very specific feature for a single purpose I guess that we wouldn't run into any problems with this approach in the future.
I'm affraid the dependencies are quite extensive, at least if we use the class "as is". I tried to see what it's like when I remove the "SVG export" feature from GraphicsSVG. This feature allows to export SVG images in the diagram as branches in the final SVG tree (in the export file) instead of converting them twice (to draw2D, then to SVG). I guess we don't need it, do we? Anyway, files needed only for this feature are prefixed with "(*)" below. GraphicsSVG itself (the class providing an adaptor between draw2D and Java2D and returning a SVG dom) has 5 internal dependencies: import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.graphics.GraphicsToGraphics2DAdaptor; import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.SVGColorConverter; import org.eclipse.gmf.runtime.draw2d.ui.render.internal.DrawableRenderedImage; import org.eclipse.gmf.runtime.draw2d.ui.render.internal.RenderingListener; (*) import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.SVGImage; GraphicsToGraphics2DAdaptor, its parent class, has 2 more internal dependencies: import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.image.ImageConverter; import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.metafile.GdiFont; And SVGImage needs 5 other internal classes: (*) import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.Draw2dRenderPlugin; (*) import org.eclipse.gmf.runtime.draw2d.ui.render.internal.AbstractRenderedImage; (*) import org.eclipse.gmf.runtime.draw2d.ui.render.internal.Draw2dRenderDebugOptions; (*) import org.eclipse.gmf.runtime.draw2d.ui.render.internal.Draw2dRenderStatusCodes; (*) import org.eclipse.gmf.runtime.draw2d.ui.render.internal.factory.RenderedImageKey; To sum up, we'll need to cop 7 classes (including GraphicsSVG) if we drop the "export SVG images within the diagram" feature, or 12 if we don't. Of course, whatever the solution we choose, this will also add OSGi dependencies to GMF public API, Batik, org.w3c.dom.svg, draw2D and SWT.
Created attachment 214678 [details] First patch, including projects settings changes for API version problems Ok, so it works. I removed the "export SVG images within the diagram", and copied 6 files (seems SVGColorConverter wasn't needed after all) from GMF to a new package in JWT-WE (org.eclipse.jwt.we.misc.util.internal.gmf). It may require a bit of tuning: there is still some problems with text clipping. I had to add two problem filters in order to make this work, because of the API change: a method was added to SaveImage. Obviously I should remove them and update the version number before one could commit the patch, but then it breaks compatibility with older diagrams, even though it shouldn't (nothing really important changed). I tried to find something in the wiki, but the closest instructions I found (http://wiki.eclipse.org/JWT_Modifications#Integrating_new_Features_into_JWT-WE) were in German and do not seem related to version compatibility.
Hi Yoann Say, Christmas seems to come early this year :) Please improve the following before eating the pudding though : * not a good idea to disable API checking ! Rather, put it in another class SaveImageSVG so you won't have to increment the existing version, or already handle the upcoming 1.2 version that will be needed anyway (enrich the Converter code to handle the new version by just updating the version tag) * take the opportunity to better say what SaveImage does : saveImage() /** saves image using SWT capabilities ex. 1 2 3 */ and saveImageSVG() as well Regards, Marc
Created attachment 214717 [details] Second, clean patch including JWT version update Here you go! I agree with you, disabling warnings/errors is bad practice, and not only in this case. This new patch includes everything that was good from the last one: * added 6 files in a new "org.eclipse.jwt.we.misc.util.internal.gmf" package * modified SaveImage and SaveImageHandler to handle SVG export * I removed the API problem filters. If you have already applied it locally, you might have to remove them manually (Project > Properties > Plug-in Development > API problem filters). What's new: * added some doc to SaveImage * handled IP issues, by adding a mention "Imported from the GMF project - http://www.eclipse.org/modeling/gmp/?project=gmf-runtime" * updated the "contribution" section in the few files I modified (I don't know if my changes were important enough to do so; if not, tell me and I'll remove them) * changed JWT version to 1.2.0.qualifier (manifests and feature.xml's) except for jwt-wam-api, which seems to have its own lifeccle * updated the Converter to correctly handle 1.1.0 files Hope it'll be OK :)
Hi Yoann Nice work, committed ! It is very useful because SVG will allow more clean & professional uses of images generated by JWT. And anyway we had to upgrade the version of JWT... Regards, Marc
I added some comments to the files copied from the GMF project in revision 1101. These point to the original classes.
