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 Maxime Bégnis <ma...@neodoc.biz> on 2010/09/01 17:36:39 UTC
fonts URL resolution
Hi list,
I am using an URIResolver with FOP to resolve the URL of external
images. I found out that it tries to find fonts using the URIResolver
before using the font base URL specified with
fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/")
Is there a way to make it use the URIResolver after(or not at all) the
specified font base URL?
Here is the code I'm using :
fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/");
fopFactory.setUserConfig(new File(FOP_USER_CFG));
OutputStream os = new
BufferedOutputStream(FileUtils.openOutputStream(result));
FOUserAgent uagent = fopFactory.newFOUserAgent();
uagent.setURIResolver(resolver);
Fop fop = fopFactory.newFop(format, uagent, os);
All this with FOP 1.0
Thanks a lot!
Maxime B�gnis
Re: FOP Output Stream
Posted by Julien Aymé <ju...@gmail.com>.
Hello,
you might want to use a temp file first, and then, send the data to
the client using a serialization trick in which you don't have to load
the whole file in memory before serializing the object.
I've attached a .java file which shows how to achieve that.
HTH,
Regards,
Julien
2010/9/6 Jeremias Maerki <de...@jeremias-maerki.ch>:
> With such an API, you probably don't have a choice but to use a single
> byte array, unless you can send over ordered chunks.....
>
> On 02.09.2010 15:10:43 Eric Douglas wrote:
>> I'm not sure. �It's embedded code. �I'm guessing they're using sockets. �I'm just calling cloneAsClientObject.
>> http://www.basis.com/onlinedocs/documentation/sysguimethods5/bbjapi_cloneasclientobject.htm
>>
>>
>> -----Original Message-----
>> From: Julien Aym� [mailto:julien.ayme@gmail.com]
>> Sent: Thursday, September 02, 2010 8:39 AM
>> To: fop-users@xmlgraphics.apache.org
>> Subject: Re: FOP Output Stream
>>
>> Hello,
>>
>> How do you send the generated output from the server to the client?
>> If you're sending bytes through a Socket, then a SocketOutputStream is the best way (use Socket#getOutputStream).
>> If you're saving the bytes into a temp file, then you could use a FileOutputStream.
>>
>> (Both of them must be wrapped in a BufferedOutputStream for better performances).
>>
>> HTH,
>>
>> Regards,
>> Julien
>>
>> 2010/9/2 Eric Douglas <ed...@blockhouse.com>:
>> > So, a BufferedOutputStream is better if you're going to produce output on the same machine, or is there a better way of doing what I'm doing?
>> >
>> > I use a ByteArrayOutputStream because I am running the program on the server. �That's where I generate my XML input and where I do the transform. �Then I need to copy the output to the client PC (running embedded code in webstart) because that's where I do all the output.
>> > I currently don't have the printers set up on the server, we use client printers. �I prefer to create the PDF directly on the client rather than save it to the server then copy it down. �Of course the print preview, using the FOP PreviewPanel, must be run on the client.
>> > I don't see any method in BufferedOutputStream to get the bytes, and it doesn't appear to be serializable, so a ByteArrayOutputStream seemed the best logical output.
>> >
>> > -----Original Message-----
>> > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
>> > Sent: Thursday, September 02, 2010 7:13 AM
>> > To: fop-users@xmlgraphics.apache.org
>> > Subject: Re: fonts URL resolution
>> >
>> >> Le 01/09/2010 17:55, Eric Douglas a �crit :
>> >> > I don't know about a simple solution but there is a workaround.
>> >> > I solved this or a related issue by not using the setFontBaseURL method.
>> >> > I use the Renderer.setFontList method instead to manually load in
>> >> > the custom font(s).
>> >> > Is there a point to using a BufferedOutputStream? �I use a
>> >> > ByteArrayOutputStream, so I have the output in bytes so I can copy
>> >> > it from server to client.
>> >
>> > Yes. A ByteArrayOutputStream buffers the whole stream in memory which can cause problems if you deal with bigger documents. A BufferedOutputStream allows maximum performance with only minimal memory consumption. It will even be faster than the ByteArrayOutputStream because at least the Sun implementation reallocates bigger and bigger chunks of memory and has to copy the whole content of the old buffer over to the new one. At least the implementation I wrote for Apache Commons IO doesn't do the copying but only allocates additional buffers.
>> > Still, the memory problem remains.
>> >
>> >
>> > 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: FOP Output Stream
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
With such an API, you probably don't have a choice but to use a single
byte array, unless you can send over ordered chunks.....
On 02.09.2010 15:10:43 Eric Douglas wrote:
> I'm not sure. It's embedded code. I'm guessing they're using sockets. I'm just calling cloneAsClientObject.
> http://www.basis.com/onlinedocs/documentation/sysguimethods5/bbjapi_cloneasclientobject.htm
>
>
> -----Original Message-----
> From: Julien Aymé [mailto:julien.ayme@gmail.com]
> Sent: Thursday, September 02, 2010 8:39 AM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP Output Stream
>
> Hello,
>
> How do you send the generated output from the server to the client?
> If you're sending bytes through a Socket, then a SocketOutputStream is the best way (use Socket#getOutputStream).
> If you're saving the bytes into a temp file, then you could use a FileOutputStream.
>
> (Both of them must be wrapped in a BufferedOutputStream for better performances).
>
> HTH,
>
> Regards,
> Julien
>
> 2010/9/2 Eric Douglas <ed...@blockhouse.com>:
> > So, a BufferedOutputStream is better if you're going to produce output on the same machine, or is there a better way of doing what I'm doing?
> >
> > I use a ByteArrayOutputStream because I am running the program on the server. That's where I generate my XML input and where I do the transform. Then I need to copy the output to the client PC (running embedded code in webstart) because that's where I do all the output.
> > I currently don't have the printers set up on the server, we use client printers. I prefer to create the PDF directly on the client rather than save it to the server then copy it down. Of course the print preview, using the FOP PreviewPanel, must be run on the client.
> > I don't see any method in BufferedOutputStream to get the bytes, and it doesn't appear to be serializable, so a ByteArrayOutputStream seemed the best logical output.
> >
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > Sent: Thursday, September 02, 2010 7:13 AM
> > To: fop-users@xmlgraphics.apache.org
> > Subject: Re: fonts URL resolution
> >
> >> Le 01/09/2010 17:55, Eric Douglas a écrit :
> >> > I don't know about a simple solution but there is a workaround.
> >> > I solved this or a related issue by not using the setFontBaseURL method.
> >> > I use the Renderer.setFontList method instead to manually load in
> >> > the custom font(s).
> >> > Is there a point to using a BufferedOutputStream? I use a
> >> > ByteArrayOutputStream, so I have the output in bytes so I can copy
> >> > it from server to client.
> >
> > Yes. A ByteArrayOutputStream buffers the whole stream in memory which can cause problems if you deal with bigger documents. A BufferedOutputStream allows maximum performance with only minimal memory consumption. It will even be faster than the ByteArrayOutputStream because at least the Sun implementation reallocates bigger and bigger chunks of memory and has to copy the whole content of the old buffer over to the new one. At least the implementation I wrote for Apache Commons IO doesn't do the copying but only allocates additional buffers.
> > Still, the memory problem remains.
> >
> >
> > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Printing a Different LAST PAGE
Posted by Eric Douglas <ed...@blockhouse.com>.
That would depend on your XML and XSL, how you're printing it and where
you need to check for last page.
To mark the last page, just put this dummy block in your XSL:
</xsl:for-each>
<fo:block>
<xsl:attribute name="id">last-page</xsl:attribute>
<xsl:attribute
name="position">absolute</xsl:attribute>
<xsl:attribute name="left">0</xsl:attribute>
<xsl:attribute name="top">0</xsl:attribute>
<xsl:attribute name="width">0</xsl:attribute>
<xsl:attribute name="height">0</xsl:attribute>
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
Then if you're checking for last page in your XSL processing just get
the value of that page you just tagged.
<fo:page-number-citation ref-id="last-page"/>
If you're coding the summary into the XML, just put a tag over it like
<SUMMARY> and put a separate process instruction after the loop.
<xsl:for-each select="INVOICE_DATA">
<xsl:apply-templates select="."/>
</xsl:for-each>
<xsl:for-each select="SUMMARY">
-----Original Message-----
From: Steffanina, Jeff [mailto:Jeff.Steffanina@marriott.com]
Sent: Thursday, September 02, 2010 9:02 AM
To: fop-users@xmlgraphics.apache.org
Subject: Printing a Different LAST PAGE
I have a simple invoice to print. On the last page of the invoice, I
need to print a simple invoice summary. I have been all over the web
trying to find the best, most simple way to address this. I have not
been successful.
Can someone suggest the best simple solution to detecting and printing a
last-page?
Jeff
---------------------------------------------------------------------
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
AW: Printing a Different LAST PAGE
Posted by Georg Datterl <ge...@geneon.de>.
Hi Jeff,
I usually just add the content at the end of the flow. Maybe with a break-before, if I only want this content on the last page.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Steffanina, Jeff [mailto:Jeff.Steffanina@marriott.com]
Gesendet: Donnerstag, 2. September 2010 15:02
An: fop-users@xmlgraphics.apache.org
Betreff: Printing a Different LAST PAGE
I have a simple invoice to print. On the last page of the invoice, I
need to print a simple invoice summary. I have been all over the web
trying to find the best, most simple way to address this. I have not
been successful.
Can someone suggest the best simple solution to detecting and printing a
last-page?
Jeff
---------------------------------------------------------------------
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
Printing a Different LAST PAGE
Posted by "Steffanina, Jeff" <Je...@marriott.com>.
I have a simple invoice to print. On the last page of the invoice, I
need to print a simple invoice summary. I have been all over the web
trying to find the best, most simple way to address this. I have not
been successful.
Can someone suggest the best simple solution to detecting and printing a
last-page?
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: FOP Output Stream
Posted by Eric Douglas <ed...@blockhouse.com>.
I'm not sure. It's embedded code. I'm guessing they're using sockets. I'm just calling cloneAsClientObject.
http://www.basis.com/onlinedocs/documentation/sysguimethods5/bbjapi_cloneasclientobject.htm
-----Original Message-----
From: Julien Aymé [mailto:julien.ayme@gmail.com]
Sent: Thursday, September 02, 2010 8:39 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP Output Stream
Hello,
How do you send the generated output from the server to the client?
If you're sending bytes through a Socket, then a SocketOutputStream is the best way (use Socket#getOutputStream).
If you're saving the bytes into a temp file, then you could use a FileOutputStream.
(Both of them must be wrapped in a BufferedOutputStream for better performances).
HTH,
Regards,
Julien
2010/9/2 Eric Douglas <ed...@blockhouse.com>:
> So, a BufferedOutputStream is better if you're going to produce output on the same machine, or is there a better way of doing what I'm doing?
>
> I use a ByteArrayOutputStream because I am running the program on the server. That's where I generate my XML input and where I do the transform. Then I need to copy the output to the client PC (running embedded code in webstart) because that's where I do all the output.
> I currently don't have the printers set up on the server, we use client printers. I prefer to create the PDF directly on the client rather than save it to the server then copy it down. Of course the print preview, using the FOP PreviewPanel, must be run on the client.
> I don't see any method in BufferedOutputStream to get the bytes, and it doesn't appear to be serializable, so a ByteArrayOutputStream seemed the best logical output.
>
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Thursday, September 02, 2010 7:13 AM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: fonts URL resolution
>
>> Le 01/09/2010 17:55, Eric Douglas a écrit :
>> > I don't know about a simple solution but there is a workaround.
>> > I solved this or a related issue by not using the setFontBaseURL method.
>> > I use the Renderer.setFontList method instead to manually load in
>> > the custom font(s).
>> > Is there a point to using a BufferedOutputStream? I use a
>> > ByteArrayOutputStream, so I have the output in bytes so I can copy
>> > it from server to client.
>
> Yes. A ByteArrayOutputStream buffers the whole stream in memory which can cause problems if you deal with bigger documents. A BufferedOutputStream allows maximum performance with only minimal memory consumption. It will even be faster than the ByteArrayOutputStream because at least the Sun implementation reallocates bigger and bigger chunks of memory and has to copy the whole content of the old buffer over to the new one. At least the implementation I wrote for Apache Commons IO doesn't do the copying but only allocates additional buffers.
> Still, the memory problem remains.
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP Output Stream
Posted by Julien Aymé <ju...@gmail.com>.
Hello,
How do you send the generated output from the server to the client?
If you're sending bytes through a Socket, then a SocketOutputStream is
the best way (use Socket#getOutputStream).
If you're saving the bytes into a temp file, then you could use a
FileOutputStream.
(Both of them must be wrapped in a BufferedOutputStream for better
performances).
HTH,
Regards,
Julien
2010/9/2 Eric Douglas <ed...@blockhouse.com>:
> So, a BufferedOutputStream is better if you're going to produce output on the same machine, or is there a better way of doing what I'm doing?
>
> I use a ByteArrayOutputStream because I am running the program on the server. That's where I generate my XML input and where I do the transform. Then I need to copy the output to the client PC (running embedded code in webstart) because that's where I do all the output.
> I currently don't have the printers set up on the server, we use client printers. I prefer to create the PDF directly on the client rather than save it to the server then copy it down. Of course the print preview, using the FOP PreviewPanel, must be run on the client.
> I don't see any method in BufferedOutputStream to get the bytes, and it doesn't appear to be serializable, so a ByteArrayOutputStream seemed the best logical output.
>
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Thursday, September 02, 2010 7:13 AM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: fonts URL resolution
>
>> Le 01/09/2010 17:55, Eric Douglas a écrit :
>> > I don't know about a simple solution but there is a workaround.
>> > I solved this or a related issue by not using the setFontBaseURL method.
>> > I use the Renderer.setFontList method instead to manually load in
>> > the custom font(s).
>> > Is there a point to using a BufferedOutputStream? I use a
>> > ByteArrayOutputStream, so I have the output in bytes so I can copy
>> > it from server to client.
>
> Yes. A ByteArrayOutputStream buffers the whole stream in memory which can cause problems if you deal with bigger documents. A BufferedOutputStream allows maximum performance with only minimal memory consumption. It will even be faster than the ByteArrayOutputStream because at least the Sun implementation reallocates bigger and bigger chunks of memory and has to copy the whole content of the old buffer over to the new one. At least the implementation I wrote for Apache Commons IO doesn't do the copying but only allocates additional buffers.
> Still, the memory problem remains.
>
>
> 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
FOP Output Stream
Posted by Eric Douglas <ed...@blockhouse.com>.
So, a BufferedOutputStream is better if you're going to produce output on the same machine, or is there a better way of doing what I'm doing?
I use a ByteArrayOutputStream because I am running the program on the server. That's where I generate my XML input and where I do the transform. Then I need to copy the output to the client PC (running embedded code in webstart) because that's where I do all the output.
I currently don't have the printers set up on the server, we use client printers. I prefer to create the PDF directly on the client rather than save it to the server then copy it down. Of course the print preview, using the FOP PreviewPanel, must be run on the client.
I don't see any method in BufferedOutputStream to get the bytes, and it doesn't appear to be serializable, so a ByteArrayOutputStream seemed the best logical output.
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Thursday, September 02, 2010 7:13 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: fonts URL resolution
> Le 01/09/2010 17:55, Eric Douglas a écrit :
> > I don't know about a simple solution but there is a workaround.
> > I solved this or a related issue by not using the setFontBaseURL method.
> > I use the Renderer.setFontList method instead to manually load in
> > the custom font(s).
> > Is there a point to using a BufferedOutputStream? I use a
> > ByteArrayOutputStream, so I have the output in bytes so I can copy
> > it from server to client.
Yes. A ByteArrayOutputStream buffers the whole stream in memory which can cause problems if you deal with bigger documents. A BufferedOutputStream allows maximum performance with only minimal memory consumption. It will even be faster than the ByteArrayOutputStream because at least the Sun implementation reallocates bigger and bigger chunks of memory and has to copy the whole content of the old buffer over to the new one. At least the implementation I wrote for Apache Commons IO doesn't do the copying but only allocates additional buffers.
Still, the memory problem remains.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fonts URL resolution
Posted by Maxime Bégnis <ma...@neodoc.biz>.
Hi Jeremias,
Le 02/09/2010 13:13, Jeremias Maerki a �crit :
> Hi Maxime
>
> On 02.09.2010 10:23:29 Maxime B�gnis wrote:
>
>> Hi,
>>
>> Finally I'm using a workaround in my URIResolver setting up a new prefix
>> like "myfonts:/" which is replaced by the actual fonts base URL.
>>
> That's one way to do it. In fact, your URIResolver should return null if
> it cannot resolve a particular URI. That way the resolution is delegated
> further down the chain by FOP. I suspect your URIResolver may not be
> implemented in the best way.
>
My URIResolver resolve relative URIs against a specified base URL. The
base URL of the FO transformation (where to find images) is not always
the path to the .fo file. I guess I should use
FopFactory.setBaseURL(String base) instead?||
>
>> I wonder if the FOP behavior to use the URIResolver before the fonts
>> base URL should be the standard one.
>>
> IMO: definitely. I wouldn't want it any other way. The URIResolver is
> there to handle special URI schemes. Relative URIs should rather be
> resolved against a base URI (the font base URL in this case).
>
I understand now that if my URIResolver says to fop where a specific
file is, there is no reason to look somewhere else...
thanks.
Maxime B�gnis
>
>> Thanks.
>>
>> Maxime B�gnis
>>
>> Le 01/09/2010 17:55, Eric Douglas a �crit :
>>
>>> I don't know about a simple solution but there is a workaround.
>>> I solved this or a related issue by not using the setFontBaseURL method.
>>> I use the Renderer.setFontList method instead to manually load in the
>>> custom font(s).
>>> Is there a point to using a BufferedOutputStream? I use a
>>> ByteArrayOutputStream, so I have the output in bytes so I can copy it
>>> from server to client.
>>>
> Yes. A ByteArrayOutputStream buffers the whole stream in memory which
> can cause problems if you deal with bigger documents. A
> BufferedOutputStream allows maximum performance with only minimal memory
> consumption. It will even be faster than the ByteArrayOutputStream
> because at least the Sun implementation reallocates bigger and bigger
> chunks of memory and has to copy the whole content of the old buffer
> over to the new one. At least the implementation I wrote for Apache
> Commons IO doesn't do the copying but only allocates additional buffers.
> Still, the memory problem remains.
>
>
>>> I haven't figured out yet how to get it to resolve paths properly for
>>> external image references. So far I only need one image, so I found a
>>> program to translate it to SVG code and copied it directly into my xsl.
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Maxime B�gnis [mailto:maxime@neodoc.biz]
>>> *Sent:* Wednesday, September 01, 2010 11:37 AM
>>> *To:* fop-users@xmlgraphics.apache.org
>>> *Subject:* fonts URL resolution
>>>
>>> Hi list,
>>>
>>> I am using an URIResolver with FOP to resolve the URL of external
>>> images. I found out that it tries to find fonts using the URIResolver
>>> before using the font base URL specified with
>>> fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/")
>>>
>>> Is there a way to make it use the URIResolver after(or not at all) the
>>> specified font base URL?
>>>
>>> Here is the code I'm using :
>>>
>>> fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/");
>>> fopFactory.setUserConfig(new File(FOP_USER_CFG));
>>> OutputStream os = new
>>> BufferedOutputStream(FileUtils.openOutputStream(result));
>>> FOUserAgent uagent = fopFactory.newFOUserAgent();
>>> uagent.setURIResolver(resolver);
>>> Fop fop = fopFactory.newFop(format, uagent, os);
>>>
>>> All this with FOP 1.0
>>>
>>> Thanks a lot!
>>>
>>> Maxime B�gnis
>>>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: fonts URL resolution
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Maxime
On 02.09.2010 10:23:29 Maxime Bégnis wrote:
> Hi,
>
> Finally I'm using a workaround in my URIResolver setting up a new prefix
> like "myfonts:/" which is replaced by the actual fonts base URL.
That's one way to do it. In fact, your URIResolver should return null if
it cannot resolve a particular URI. That way the resolution is delegated
further down the chain by FOP. I suspect your URIResolver may not be
implemented in the best way.
> I wonder if the FOP behavior to use the URIResolver before the fonts
> base URL should be the standard one.
IMO: definitely. I wouldn't want it any other way. The URIResolver is
there to handle special URI schemes. Relative URIs should rather be
resolved against a base URI (the font base URL in this case).
> Thanks.
>
> Maxime Bégnis
>
> Le 01/09/2010 17:55, Eric Douglas a écrit :
> > I don't know about a simple solution but there is a workaround.
> > I solved this or a related issue by not using the setFontBaseURL method.
> > I use the Renderer.setFontList method instead to manually load in the
> > custom font(s).
> > Is there a point to using a BufferedOutputStream? I use a
> > ByteArrayOutputStream, so I have the output in bytes so I can copy it
> > from server to client.
Yes. A ByteArrayOutputStream buffers the whole stream in memory which
can cause problems if you deal with bigger documents. A
BufferedOutputStream allows maximum performance with only minimal memory
consumption. It will even be faster than the ByteArrayOutputStream
because at least the Sun implementation reallocates bigger and bigger
chunks of memory and has to copy the whole content of the old buffer
over to the new one. At least the implementation I wrote for Apache
Commons IO doesn't do the copying but only allocates additional buffers.
Still, the memory problem remains.
> > I haven't figured out yet how to get it to resolve paths properly for
> > external image references. So far I only need one image, so I found a
> > program to translate it to SVG code and copied it directly into my xsl.
> >
> > ------------------------------------------------------------------------
> > *From:* Maxime Bégnis [mailto:maxime@neodoc.biz]
> > *Sent:* Wednesday, September 01, 2010 11:37 AM
> > *To:* fop-users@xmlgraphics.apache.org
> > *Subject:* fonts URL resolution
> >
> > Hi list,
> >
> > I am using an URIResolver with FOP to resolve the URL of external
> > images. I found out that it tries to find fonts using the URIResolver
> > before using the font base URL specified with
> > fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/")
> >
> > Is there a way to make it use the URIResolver after(or not at all) the
> > specified font base URL?
> >
> > Here is the code I'm using :
> >
> > fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/");
> > fopFactory.setUserConfig(new File(FOP_USER_CFG));
> > OutputStream os = new
> > BufferedOutputStream(FileUtils.openOutputStream(result));
> > FOUserAgent uagent = fopFactory.newFOUserAgent();
> > uagent.setURIResolver(resolver);
> > Fop fop = fopFactory.newFop(format, uagent, os);
> >
> > All this with FOP 1.0
> >
> > Thanks a lot!
> >
> > Maxime Bégnis
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: fonts URL resolution
Posted by Maxime Bégnis <ma...@neodoc.biz>.
Hi,
Finally I'm using a workaround in my URIResolver setting up a new prefix
like "myfonts:/" which is replaced by the actual fonts base URL.
I wonder if the FOP behavior to use the URIResolver before the fonts
base URL should be the standard one.
Thanks.
Maxime B�gnis
Le 01/09/2010 17:55, Eric Douglas a �crit :
> I don't know about a simple solution but there is a workaround.
> I solved this or a related issue by not using the setFontBaseURL method.
> I use the Renderer.setFontList method instead to manually load in the
> custom font(s).
> Is there a point to using a BufferedOutputStream? I use a
> ByteArrayOutputStream, so I have the output in bytes so I can copy it
> from server to client.
> I haven't figured out yet how to get it to resolve paths properly for
> external image references. So far I only need one image, so I found a
> program to translate it to SVG code and copied it directly into my xsl.
>
> ------------------------------------------------------------------------
> *From:* Maxime B�gnis [mailto:maxime@neodoc.biz]
> *Sent:* Wednesday, September 01, 2010 11:37 AM
> *To:* fop-users@xmlgraphics.apache.org
> *Subject:* fonts URL resolution
>
> Hi list,
>
> I am using an URIResolver with FOP to resolve the URL of external
> images. I found out that it tries to find fonts using the URIResolver
> before using the font base URL specified with
> fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/")
>
> Is there a way to make it use the URIResolver after(or not at all) the
> specified font base URL?
>
> Here is the code I'm using :
>
> fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/");
> fopFactory.setUserConfig(new File(FOP_USER_CFG));
> OutputStream os = new
> BufferedOutputStream(FileUtils.openOutputStream(result));
> FOUserAgent uagent = fopFactory.newFOUserAgent();
> uagent.setURIResolver(resolver);
> Fop fop = fopFactory.newFop(format, uagent, os);
>
> All this with FOP 1.0
>
> Thanks a lot!
>
> Maxime B�gnis
RE: fonts URL resolution
Posted by Eric Douglas <ed...@blockhouse.com>.
I don't know about a simple solution but there is a workaround.
I solved this or a related issue by not using the setFontBaseURL method.
I use the Renderer.setFontList method instead to manually load in the custom font(s).
Is there a point to using a BufferedOutputStream? I use a ByteArrayOutputStream, so I have the output in bytes so I can copy it from server to client.
I haven't figured out yet how to get it to resolve paths properly for external image references. So far I only need one image, so I found a program to translate it to SVG code and copied it directly into my xsl.
________________________________
From: Maxime Bégnis [mailto:maxime@neodoc.biz]
Sent: Wednesday, September 01, 2010 11:37 AM
To: fop-users@xmlgraphics.apache.org
Subject: fonts URL resolution
Hi list,
I am using an URIResolver with FOP to resolve the URL of external images. I found out that it tries to find fonts using the URIResolver before using the font base URL specified with fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/" <file:///path/to/fonts/> )
Is there a way to make it use the URIResolver after(or not at all) the specified font base URL?
Here is the code I'm using :
fopFactory.getFontManager().setFontBaseURL("file:///path/to/fonts/" <file:///path/to/fonts/> );
fopFactory.setUserConfig(new File(FOP_USER_CFG));
OutputStream os = new BufferedOutputStream(FileUtils.openOutputStream(result));
FOUserAgent uagent = fopFactory.newFOUserAgent();
uagent.setURIResolver(resolver);
Fop fop = fopFactory.newFop(format, uagent, os);
All this with FOP 1.0
Thanks a lot!
Maxime Bégnis