You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Anthony Cavalliotis <an...@googlemail.com> on 2005/11/26 20:28:06 UTC
freehep and batik
Hi,
I notice some of you have got SVG -> EMF (or similar) working via
batik and freehep. (Nice as it means that for biz users wanting
formats natively supported by MS Powerpoint and Word as output they
are catered for)
At least by following the (old) thread at
http://koala.ilog.fr/batik/mlists/batik-users/archives/msg07218.html
that's the impression I get.
For newbie of batik can the original poster or someone "in the know"
post a more fuller code example? ie the Foo JComponent working with
the http://xml.apache.org/batik/svgcanvas.html code example?
FYI to save to emf is easy with freehep provided a genuine java2d
Component exists. The original post refers to a Foo class (his
creation) that somehow wraps a non genuine java2d JSVGCanvas and uses
a GVTTreeWalker to paint java2d.
Anyhow using Foo, code to save for freehep newbies would be :
// --- snip
import org.freehep.graphicsio.emf.EMFExportFileType;
EMFExportFileType emfExportFileType = new EMFExportFileType();
Foo foo = new Foo(); // original posters foo JComponent .. need
fuller code here
emfExportFileType.exportToFile(new File("c:\\foo.emf"), foo,
null, null, null);
// --- snip
Any takers to create a cut and paste example?
Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: freehep and batik
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Yes, that is currently so. Until the board votes on a resolution that
allows this, it is impossible. The last resolution that was suggested
somehow didn't pass. I'd have to look up the details. But the idea is to
allow just that AFAIK: Creating components based on LGPL-based libraries
under the ALv2, but not allowing the redistribution of LGPL libraries.
One of the biggest issues was to get the FSF to publicly state how the
LGPL is to be interpreted WRT Java, because there were major question
marks there.
On 02.12.2005 12:13:17 thomas.deweese wrote:
> Hi Jeremias,
>
> Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 12/01/2005 02:42:35 PM:
>
> > Nice idea, but unfortunately, FreeHEP is licensed under the LGPL which
> > currently makes it off-limits for any Apache project. You could,
> however,
> > publish such a transcoder somewhere else and under the LGPL.
>
> Is this right? I was under the impression that one of the key
> distinctions between GPL and LGPL is that code depending on LGPL
> could be under a separate license from the 'library' code (in this
> case freeHEP). So we certainly couldn't distribute the FreeHEP
> jar files but I would have thought that one could include a freeHEP
> transcoder under say the 'contrib' tree (which isn't normally built).
> With the code in the transcoder under Apache License.
>
> > I've been keeping an eye on FreeHEP for ages now since they've got a
> nice
> > PostScript interpreter that I'd love to use in FOP. But I can't because
> > of the LGPL. Fortunately, this situation may yet change in the near
> > future.
>
> I have no idea about the quality of the code but it certainly looks
> interesting from a sheer functionality point of view....
>
> > On 01.12.2005 19:22:39 Anthony Cavalliotis wrote:
> > <snip/>
> > > I'd be interested to see any Transcoder re-implementation (or a start)
> > > if someone has the time. Then you could add it as an (optional) part
> > > of batik (cause you'd need the freehep jar). Looking at the other
> > > (printer, image) transcoders in org.apache.batik.transcoder, I agree
> > > that a cleaner solution (for future reuse) would best be a
> > > EMFTranscoder.
> > <snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: freehep and batik
Posted by th...@kodak.com.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 12/01/2005 02:42:35 PM:
> Nice idea, but unfortunately, FreeHEP is licensed under the LGPL which
> currently makes it off-limits for any Apache project. You could,
however,
> publish such a transcoder somewhere else and under the LGPL.
Is this right? I was under the impression that one of the key
distinctions between GPL and LGPL is that code depending on LGPL
could be under a separate license from the 'library' code (in this
case freeHEP). So we certainly couldn't distribute the FreeHEP
jar files but I would have thought that one could include a freeHEP
transcoder under say the 'contrib' tree (which isn't normally built).
With the code in the transcoder under Apache License.
> I've been keeping an eye on FreeHEP for ages now since they've got a
nice
> PostScript interpreter that I'd love to use in FOP. But I can't because
> of the LGPL. Fortunately, this situation may yet change in the near
> future.
I have no idea about the quality of the code but it certainly looks
interesting from a sheer functionality point of view....
> On 01.12.2005 19:22:39 Anthony Cavalliotis wrote:
> <snip/>
> > I'd be interested to see any Transcoder re-implementation (or a start)
> > if someone has the time. Then you could add it as an (optional) part
> > of batik (cause you'd need the freehep jar). Looking at the other
> > (printer, image) transcoders in org.apache.batik.transcoder, I agree
> > that a cleaner solution (for future reuse) would best be a
> > EMFTranscoder.
> <snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: freehep and batik
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Nice idea, but unfortunately, FreeHEP is licensed under the LGPL which
currently makes it off-limits for any Apache project. You could, however,
publish such a transcoder somewhere else and under the LGPL. I've been
keeping an eye on FreeHEP for ages now since they've got a nice
PostScript interpreter that I'd love to use in FOP. But I can't because
of the LGPL. Fortunately, this situation may yet change in the near
future.
On 01.12.2005 19:22:39 Anthony Cavalliotis wrote:
<snip/>
> I'd be interested to see any Transcoder re-implementation (or a start)
> if someone has the time. Then you could add it as an (optional) part
> of batik (cause you'd need the freehep jar). Looking at the other
> (printer, image) transcoders in org.apache.batik.transcoder, I agree
> that a cleaner solution (for future reuse) would best be a
> EMFTranscoder.
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: freehep and batik
Posted by Anthony Cavalliotis <an...@googlemail.com>.
Worked out my problem. The SVG file had lots of clipPaths in it which
caused occlusions in the output emf. Right-clicking the emf within
word and choosing edit picture caused the whole picture to show. Was
banging my head as to why emf wasn't working when a collegue by chance
(or divine genius) tried this right click edit picture thing.
So freehep *was* working, I just had to get rid of the clip regions
... so I in changed
SVG2EMF.java (previous post) to use a GraphicsDelegate like so:
// -- snip
public void paint(Graphics g) {
this.g = (Graphics2D) g;
if (gvtTreeWalker != null) {
gvtTreeWalker.getRoot().paint(new
GraphicsDelegate((Graphics2D) this.g));
}
}
// -- snip
where GraphicsDelegate.java
// -- snip
public class GraphicsDelegate extends Graphics2D {
Graphics2D g;
public GraphicsDelegate(Graphics2D g) {
this.g = g;
}
public void rotate(double theta) {
g.rotate(theta);
}
...
public void clip(Shape s) {
//g.clip(s);
}
...
}
// -- snip
does everything a regular graphics2d does, minus the commented out clipping.
So, "happy days" as far as a drop in place example goes.
I'd be interested to see any Transcoder re-implementation (or a start)
if someone has the time. Then you could add it as an (optional) part
of batik (cause you'd need the freehep jar). Looking at the other
(printer, image) transcoders in org.apache.batik.transcoder, I agree
that a cleaner solution (for future reuse) would best be a
EMFTranscoder.
FYI -- EMF does supports rasterised + vector stuff so I dont know if
its strictly a image transcoder?
Anthony
On 29/11/05, thomas.deweese@kodak.com <th...@kodak.com> wrote:
> Hi Anthony,
>
> Anthony Cavalliotis <an...@googlemail.com> wrote on
> 11/28/2005 06:21:53 PM:
>
> > > I'm not sure why you think the JSVGCanvas is not a 'true'
> Component.
> > Ignorance probably. What I meant was that to get a tree of sub
> > components I have to fetch a GVTTree rather than relying on a
> > structure such as:
>
> Ok, I see. The real problem isn't if it's a component it's
> that it manages it's own offscreen buffer and so all the freehep
> will see is the final BufferedImage which makes the whole thing
> moot.
>
> > > The real question is if you are trying to simply transcode why are you
> > > creating a component. I would look at subclassing
> > > batik.transcoder.SVGAbstractTranscoder this class will read an SVG
> file
> > > and build the GVT tree. Then you can more or less just call
> > > 'paint' on the root GVT node passing in the FreeHEP EMF Graphics2D.
> >
> > The SVGAbstractTranscoder is a good idea. Beforehand though, I got
> > something working with the JComponent approach which I'll include here
> > for anyone interested. Its a cut and paste modification of the
> > JSVGCanvas code with two files (1) SimpleEMFWriter.java (main
> > program); and (2) SVG2EMF.java (helper with the GVTTree) [apols for
> > the spew of inline code here]
>
> I think the Transcoder route would give you a much cleaner solution.
>
> > Even though the above works for simple svgs, complex ones (the ones I
> > need to convert) don't work. Things like boxes with a certain edge
> > shade/font missing. Can't really tell without doing more tests but
> > I'm thinking that there is something wrong with the freehep conversion
> > (or the styles/fonts batik uses for SVG might be nonstandard?). Not
> > sure if anyone has encountered this but I'll try and look at the
> > freehep forums and dig up (and post back) any answers.
>
> If you can post a 'before and after' example it might be helpful.
> Two comments that might help a little. First, the way you are using
> Batik all of your text will be drawn as shapes (using drawGlyphVector),
> so I doubt the fonts are at issue. There is some chance that there
> is a bug in the way EMFGraphics2D handles drawGlyphVector but the code
> to implement this is pretty simple.
>
> Second, I would suspect the problem is when Batik has to rasterize
> content. This tends to happen when filters are used (which would
> explain the failure for 'complex' cases). Do you know if the EMF
> graphics supports embedding raster content?
>
> > If I don't get this licked I *could* convert SVG->PS/PDF->EMF via
> > Apache FOP and pstoedit (or similar), but it seems like a horrible
> > kludge and requires lots of dlls etc on the pstoedit side (results are
> > near perfect though). Argh ... Surely someone has a nice (conversion
> > perfect) complete (pref Java) solution? Damn M$ and their closed
> > standards.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: freehep and batik
Posted by th...@kodak.com.
Hi Anthony,
Anthony Cavalliotis <an...@googlemail.com> wrote on
11/28/2005 06:21:53 PM:
> > I'm not sure why you think the JSVGCanvas is not a 'true'
Component.
> Ignorance probably. What I meant was that to get a tree of sub
> components I have to fetch a GVTTree rather than relying on a
> structure such as:
Ok, I see. The real problem isn't if it's a component it's
that it manages it's own offscreen buffer and so all the freehep
will see is the final BufferedImage which makes the whole thing
moot.
> > The real question is if you are trying to simply transcode why are you
> > creating a component. I would look at subclassing
> > batik.transcoder.SVGAbstractTranscoder this class will read an SVG
file
> > and build the GVT tree. Then you can more or less just call
> > 'paint' on the root GVT node passing in the FreeHEP EMF Graphics2D.
>
> The SVGAbstractTranscoder is a good idea. Beforehand though, I got
> something working with the JComponent approach which I'll include here
> for anyone interested. Its a cut and paste modification of the
> JSVGCanvas code with two files (1) SimpleEMFWriter.java (main
> program); and (2) SVG2EMF.java (helper with the GVTTree) [apols for
> the spew of inline code here]
I think the Transcoder route would give you a much cleaner solution.
> Even though the above works for simple svgs, complex ones (the ones I
> need to convert) don't work. Things like boxes with a certain edge
> shade/font missing. Can't really tell without doing more tests but
> I'm thinking that there is something wrong with the freehep conversion
> (or the styles/fonts batik uses for SVG might be nonstandard?). Not
> sure if anyone has encountered this but I'll try and look at the
> freehep forums and dig up (and post back) any answers.
If you can post a 'before and after' example it might be helpful.
Two comments that might help a little. First, the way you are using
Batik all of your text will be drawn as shapes (using drawGlyphVector),
so I doubt the fonts are at issue. There is some chance that there
is a bug in the way EMFGraphics2D handles drawGlyphVector but the code
to implement this is pretty simple.
Second, I would suspect the problem is when Batik has to rasterize
content. This tends to happen when filters are used (which would
explain the failure for 'complex' cases). Do you know if the EMF
graphics supports embedding raster content?
> If I don't get this licked I *could* convert SVG->PS/PDF->EMF via
> Apache FOP and pstoedit (or similar), but it seems like a horrible
> kludge and requires lots of dlls etc on the pstoedit side (results are
> near perfect though). Argh ... Surely someone has a nice (conversion
> perfect) complete (pref Java) solution? Damn M$ and their closed
> standards.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: freehep and batik
Posted by Anthony Cavalliotis <an...@googlemail.com>.
> I'm not sure why you think the JSVGCanvas is not a 'true' Component.
Ignorance probably. What I meant was that to get a tree of sub
components I have to fetch a GVTTree rather than relying on a
structure such as:
JComponent parent = new SomeJComponent()
JComponent someChild = new SomeOtherJComponent()
parent.add(someChild);
someChild.add(new anotherchildJComp());
etc.
which freehep relies upon.
> The real question is if you are trying to simply transcode why are you
> creating a component. I would look at subclassing
> batik.transcoder.SVGAbstractTranscoder this class will read an SVG file
> and build the GVT tree. Then you can more or less just call
> 'paint' on the root GVT node passing in the FreeHEP EMF Graphics2D.
The SVGAbstractTranscoder is a good idea. Beforehand though, I got
something working with the JComponent approach which I'll include here
for anyone interested. Its a cut and paste modification of the
JSVGCanvas code with two files (1) SimpleEMFWriter.java (main
program); and (2) SVG2EMF.java (helper with the GVTTree) [apols for
the spew of inline code here]
// SVG2EMF.java
import org.apache.batik.gvt.GVTTreeWalker;
import org.apache.batik.swing.JSVGCanvas;
import org.apache.batik.swing.svg.GVTTreeBuilderEvent;
import org.apache.batik.swing.svg.GVTTreeBuilderListener;
import org.freehep.graphics2d.VectorGraphics;
import org.freehep.graphicsio.emf.EMFGraphics2D;
import javax.swing.*;
import java.awt.*;
import java.io.File;
import java.io.FileNotFoundException;
public class SVG2EMF
extends JComponent
implements GVTTreeBuilderListener {
private Graphics2D g = null;
JSVGCanvas svgCanvas = new JSVGCanvas();
GVTTreeWalker gvtTreeWalker = null;
String URI;
public SVG2EMF() {
}
public void setURI(String URI) {
this.URI = URI;
svgCanvas.addGVTTreeBuilderListener(this);
svgCanvas.setURI(URI);
}
public void export(File file) throws FileNotFoundException {
VectorGraphics v = new EMFGraphics2D(
file, (Dimension) svgCanvas.getSVGDocumentSize());
v.startExport();
this.print(v);
v.endExport();
}
public void paint(Graphics g) {
this.g = (Graphics2D) g;
if (gvtTreeWalker != null) {
gvtTreeWalker.getRoot().paint((Graphics2D) this.g);
}
}
public void gvtBuildStarted(GVTTreeBuilderEvent event) {
//To change body of implemented methods use File | Settings |
File Templates.
}
public void gvtBuildCompleted(GVTTreeBuilderEvent e) {
gvtTreeWalker = new GVTTreeWalker(
svgCanvas.getGraphicsNode());
super.repaint();
}
public void gvtBuildCancelled(GVTTreeBuilderEvent event) {
//To change body of implemented methods use File | Settings |
File Templates.
}
public void gvtBuildFailed(GVTTreeBuilderEvent event) {
//To change body of implemented methods use File | Settings |
File Templates.
}
}
// -- SimpleEMFWriter.java
import org.freehep.graphicsio.emf.EMFExportFileType;
import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.io.File;
import java.io.IOException;
public class SimpleEMFWriter {
public static void main(String[] args) {
JFrame f = new JFrame("Batik");
SimpleEMFWriter app = new SimpleEMFWriter(f);
f.getContentPane().add(app.createComponents());
f.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});
f.setSize(400, 400);
f.setVisible(true);
}
JFrame frame;
JButton button = new JButton("Load...");
JButton saveButton = new JButton("Save EMF");
JLabel label = new JLabel();
SVG2EMF svgObj = new SVG2EMF();
final EMFExportFileType emfExportFileType = new EMFExportFileType();
public SimpleEMFWriter(JFrame f) {
frame = f;
}
public JComponent createComponents() {
final JPanel panel = new JPanel(new BorderLayout());
JPanel p = new JPanel(new FlowLayout(FlowLayout.LEFT));
p.add(button);
p.add(label);
JPanel southPanel = new JPanel(new FlowLayout(FlowLayout.LEFT));
southPanel.add(saveButton);
panel.add("North", p);
panel.add("Center", svgObj);
panel.add("South", southPanel);
// Set the button action.
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent ae) {
JFileChooser fc = new JFileChooser(".");
int choice = fc.showOpenDialog(panel);
if (choice == JFileChooser.APPROVE_OPTION) {
File f = fc.getSelectedFile();
try {
svgObj.setURI(f.toURL().toString());
} catch (IOException ex) {
ex.printStackTrace();
}
}
}
});
saveButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent ae) {
try {
svgObj.export(new File("c:\\filename.emf"));
} catch (IOException e) {
e.printStackTrace(); //To change body of catch
statement use File | Settings | File Templates.
}
}
});
return panel;
}
}
> > Any takers to create a cut and paste example?
>
> Sorry I don't have cut and paste code but I will try and help you
> create such code ;)
Nice :)
Even though the above works for simple svgs, complex ones (the ones I
need to convert) don't work. Things like boxes with a certain edge
shade/font missing. Can't really tell without doing more tests but
I'm thinking that there is something wrong with the freehep conversion
(or the styles/fonts batik uses for SVG might be nonstandard?). Not
sure if anyone has encountered this but I'll try and look at the
freehep forums and dig up (and post back) any answers.
If I don't get this licked I *could* convert SVG->PS/PDF->EMF via
Apache FOP and pstoedit (or similar), but it seems like a horrible
kludge and requires lots of dlls etc on the pstoedit side (results are
near perfect though). Argh ... Surely someone has a nice (conversion
perfect) complete (pref Java) solution? Damn M$ and their closed
standards.
Cheers,
Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: freehep and batik
Posted by th...@kodak.com.
Hi Anthony,
Anthony Cavalliotis <an...@googlemail.com> wrote on
11/26/2005 02:28:06 PM:
> I notice some of you have got SVG -> EMF (or similar) working via
> batik and freehep. (Nice as it means that for biz users wanting
> formats natively supported by MS Powerpoint and Word as output they
> are catered for)
So I've never used FreeHEP, but I took a look at the
message you mentioned, and glimpsed briefly at the FreeHEP javadoc.
> At least by following the (old) thread at
> http://koala.ilog.fr/batik/mlists/batik-users/archives/msg07218.html
> that's the impression I get.
>
> For newbie of batik can the original poster or someone "in the know"
> post a more fuller code example? ie the Foo JComponent working with
> the http://xml.apache.org/batik/svgcanvas.html code example?
>
> FYI to save to emf is easy with freehep provided a genuine java2d
> Component exists.
I'm not sure why you think the JSVGCanvas is not a 'true' Component.
The real question is if you are trying to simply transcode why are you
creating a component. I would look at subclassing
batik.transcoder.SVGAbstractTranscoder this class will read an SVG file
and build the GVT tree. Then you can more or less just call
'paint' on the root GVT node passing in the FreeHEP EMF Graphics2D.
> Any takers to create a cut and paste example?
Sorry I don't have cut and paste code but I will try and help you
create such code ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org