Re: fonts URL resolution

[Maxime Bégnis]

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:max...@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-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

   
<<attachment: maxime.vcf>>---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org