SWT and SVG in standalone bpplication

java-programmer, SWT and SVG in standalone bpplication Hello!

I am developing a standalone application using the SWT framework;
however, the application will not be based on the eclipse rich client.

I like to integrate SVG graphics into my application; more precisely, I
would like to render SVG graphics to arbitrary positions on a Canvas. Is
there a convenient way to do so? I already checked the Apache Batik
project, but this one does not integrate with SWT. The Holongate project
does only provide plugins for Eclipse, which I can not use when I do not
use the Eclipse platform.

Thank you for hints!
Best regards, Bernhard

java-programmer >> SWT and SVG in standalone bpplication Bernhard Schandl wrote:
> Hello!
>
> I am developing a standalone application using the SWT framework;
> however, the application will not be based on the eclipse rich client.
>
> I like to integrate SVG graphics into my application; more precisely, I
> would like to render SVG graphics to arbitrary positions on a Canvas. Is
> there a convenient way to do so? I already checked the Apache Batik
> project, but this one does not integrate with SWT. The Holongate project
> does only provide plugins for Eclipse, which I can not use when I do not
> use the Eclipse platform.
>

I am developing in SWT also (though I am using Eclipse) so your post
was of interest. Not that I have looked into SVG, and perhaps you have
looked into this in more depth, but doesn't the Holongate project
support stand-alone (i.e. without Eclipse)?

begin from the Holongate project http://www.holongate.org/contents.html

Starting with the v2.0 release, Java2D for SWT is available for
download as a:

Set of plugins for those who want to integrate it inside the Eclipse
workbench,
(or)
Standalone library to build and redistribute SWT-based applications.

(and also)

Get access to the Java2D features inside the SWT toolkit and increase
its graphical capabilities with:

Antialiasing,
Transparency,
True vector representation of shapes (i.e. arbitrary precision of
coordinates)
User defined transformations for scaling, rotation, ...
Separation of the geometry representation and the rendering process,

end from Holongate project

Reading the above implies to me that you don't have to use Eclipse to
utilize the library for your SVG support.

Kind of off track from your post, but now I'm curious:

Holongate also refrences the "expanded" capabilities of Java2D in SWT.
I compared SWT to 2D and have not found significant difference for
arbitrary graphics. Using SWT.GC I have been able to do antialiasing
with GC.setAntialias() method. Transparency with the GC.setAlpha().
Transformations with GC.setTransform() for scaling and rotation.
Separation of geometry and rendering with the SWT.Path class and
GC.drawPath(). And the performance is awesome.

Not sure I understand the difference between true vector representation
and separation of geometry since the SWT.Path class can contain
multiple separate drawing objects in a single instance. So, you only
have to call drawPath() once for your whole display. In otherwords,
with one call your whole display can be painted by native code[1].
Path also utilizes float coordinates so you can draw your vectors in
the problem space. GC.setTransform() maps the problem space
coordinates to drawing space, again in native code.

Is their info on what is available for native rendering with SWT out of
date or something?

[1] Unless for example you have multiple line widths. Then you would
need a separate path for each set of objects you want to draw with a
given width. Which reminds me: One thing I did find annoying about
SWT... line width can only be specified as an integer, yet if you have
a scaling transformation, line width is scaled. Doesn't matter if you
set line width before or after setting the transformation. So you have
to reconcile your line width within the problem space. Line width
should be with respect to drawing space or at least a choice. But it
is only scaled if you change it. If you never call setLineWidth() you
will get a one pixel width line regardless of your transformation.
Seems like a bug.