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/12/01 19:22:39 UTC
Re: freehep and batik
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 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