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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi Anthony,
>
> Anthony Cavalliotis <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
