xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Cavalliotis <anthony.cavallio...@googlemail.com>
Subject Re: freehep and batik
Date Thu, 01 Dec 2005 18:22:39 GMT
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) {
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) {
     public void clip(Shape 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

FYI -- EMF does supports rasterised + vector stuff so I dont know if
its strictly a image transcoder?


On 29/11/05, thomas.deweese@kodak.com <thomas.deweese@kodak.com> wrote:
> Hi Anthony,
> Anthony Cavalliotis <anthony.cavalliotis@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

View raw message