You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Brian Trezise <Br...@IntelliData.net> on 2008/08/08 17:30:22 UTC

Upgrade to v 0.95 from 0.20.5 with custom modifications

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.

 

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?

 

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.  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;

 

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
brian.trezise@intellidata.net

 


Re: Upgrade to v 0.95 from 0.20.5 with custom modifications

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
> brian.trezise@intellidata.net
> 
> 
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch] 
> Sent: Friday, August 08, 2008 12:21 PM
> To: fop-users@xmlgraphics.apache.org
> 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
> > brian.trezise@intellidata.net
> > 
> >  
> > 



Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


RE: Upgrade to v 0.95 from 0.20.5 with custom modifications

Posted by Brian Trezise <Br...@IntelliData.net>.
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
brian.trezise@intellidata.net


-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch] 
Sent: Friday, August 08, 2008 12:21 PM
To: fop-users@xmlgraphics.apache.org
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
> brian.trezise@intellidata.net
> 
>  
> 




Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Upgrade to v 0.95 from 0.20.5 with custom modifications

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
> brian.trezise@intellidata.net
> 
>  
> 




Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org