Hmm, I'm not sure how I can help you. All I can say is that we're also
integrating PDFGraphics2D inside FOP to embed SVG in a larger PDF
document and we don't have to hack stuff like the stream filters.
Examples:
https://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFSVGHandler.java?view=markup
https://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFGraphics2DAdapter.java?view=markup
All I can say is that we do have a clear way to embed an SVG graphic in
a larger PDF document but it's probably different from what you built.
So I'm very hesitant to change anything in our source without having a
clearer picture of the context (i.e. source code) that you're using it
in (in case that's what you want).
On 08.08.2008 23:22:10 Brian Trezise wrote:
> Yes, essentially we are inserting an SVG image of a part schematic (eg a
> capacitor), and then using dynamically generated data from a database to
> describe that part.
>
>
> >> I
> >> replaced the above code with the following, but am unsure if this is the
> >> correct way to handle the situation. The goal here is to avoid breaking
> any
> >> more code than strictly necessary to perform this upgrade
> >>
> >>
> >> case FILTER_FLATE:
> >>
> >> FlateFilter ff = new FlateFilter();
> >>
> >> this.streamContent = ((FlateEncodeOutputStream)
> >> ff.applyFilter(out)).toString().getBytes();
> >>
> >> PDFEntry flate = new PDFEntry("/Filter","/FlateDecode");
> >>
> >> dictionary.add(flate);
> >>
> >> break;
> >
> >And what exactly are you trying to do here? I don't get it.
>
> I'm trying to convert the OutputStream back to a byte array for backward
> compatibility with the rest of our software; hoping not to have to rewrite
> the entire svg handler :)
> ___________________________________________________
> Brian Trezise
> Staff Software Engineer
> IntelliData, Inc
> 3173 s. uravan way
> aurora, colorado 80013
> T: 720.524.4864
> [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 08, 2008 12:21 PM
> To: [email protected]
> Subject: Re: Upgrade to v 0.95 from 0.20.5 with custom modifications
>
> On 08.08.2008 17:30:22 Brian Trezise wrote:
> > So I just upgraded us from Fop v. 0.20.5 to v 0.95 because our old version
> > of the software was not properly handling newer svg image specifications.
> > In the previous version we had to overload the PDFTranscoder class in
> order
> > to allow us to custom specify the x,y position of an SVG image on the pdf
> > page.
> >
> >
> >
> > So I guess the first question would be, is it now possible to set the x,y
> > position of a svg image within a document with v 0.95? I haven't seen
> > anything in the documentation anywhere to indicate that it is, but it
> would
> > make life much nicer if so.
>
> If Batik can't, then the PDFTranscoder can't either. The Transcoder API
> is something defined by Batik. Can you please explain to me what exactly
> you're trying to do? I get the impression that you want to convert an
> SVG to PDF, but the PDF page shall be larger than the SVG itself and
> that's why you have to position it within the page. Is that correct?
>
> I've seen in Batik that the ToSVGAbstractTranscoder contains
> TranscodingHints.Keys for X/Y-Offset. It might be an idea to add support
> for those in the PDFTranscoder if you want a clean solution rather than
> force/hack the code into submission from the outside.
>
> > Next question, assuming the answer to the first question is no: Our old
> > overload of the PDFTranscoder class used a PDFGraphics2D object,
> > instantiated with the now-"protected" PDFGraphics2D(Boolean textAsShapes)
> > constructor. I have tried to change over to the new many-argument
> > constructor however in creating a new document to send through I end up
> > getting a blank page back. Is there a way to access the protected
> > constructor (or equivalent functionality) somehow?
>
> Why do you want to interface with PDFGraphics2D? In PDFTranscoder, a
> PDFDocumentGraphics2D is used because you also need to create the PDF
> container around the SVG content.
>
> Anyway, I think it would be a lot simpler for you if you just used
> XSL-FO to position your SVG on a page. That is easily done through an
> XSLT stylesheet that wraps your SVG in an XSL-FO document (using
> fo:instream-foreign-object). Using a block-container with
> absolute-position="fixed" it's easy to position the SVG in any size
> anywhere on the page.
>
> > Lastly, we have a PDFObject class that makes use of several different
> > filters. Since all the code was the same for each filter, I'll just show
> > one example from the switch statement:
> >
> >
> >
> > The old code looked like this:
> >
> > case FILTER_FLATE:
> >
> > FlateFilter ff = new FlateFilter();
> >
> > this.streamContent = ff.encode(this.streamContent);
> >
> > PDFEntry flate = new PDFEntry("/Filter","/FlateDecode");
> >
> > dictionary.add(flate);
> >
> > break;
> >
> >
> >
> > The old encode() method took a byte array and returned a byte array;
> however
> > that method no longer exists. It appears that the replacement
> functionality
> > is "applyFilter" which takes an OutputStream and returns an OutputStream.
>
> Yes, that was optimization work to avoid buffering whole streams in
> memory. It's now faster und uses less memory.
>
> > I
> > replaced the above code with the following, but am unsure if this is the
> > correct way to handle the situation. The goal here is to avoid breaking
> any
> > more code than strictly necessary to perform this upgrade
> >
> >
> > case FILTER_FLATE:
> >
> > FlateFilter ff = new FlateFilter();
> >
> > this.streamContent = ((FlateEncodeOutputStream)
> > ff.applyFilter(out)).toString().getBytes();
> >
> > PDFEntry flate = new PDFEntry("/Filter","/FlateDecode");
> >
> > dictionary.add(flate);
> >
> > break;
>
> And what exactly are you trying to do here? I don't get it.
>
> >
> >
> > I sincerely appreciate any assistance you can offer,
> >
> > ___________________________________________________
> > Brian Trezise
> > Staff Software Engineer
> > IntelliData, Inc
> > 3173 s. uravan way
> > aurora, colorado 80013
> > T: 720.524.4864
> > [EMAIL PROTECTED]
> >
> >
> >
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
