Re: How to use a relative URI in the config file (in 'renderer/fonts/font/@embed-url')
On Jan 7, 2006, at 02:35, Paul Vinkenoog wrote: ( A bit OT, but anyways... ) I haven't tried 0.91 yet, but in 0.20.5 the above URLs did work as relative (although indeed they shouldn't). Worse: if you left out the //, they didn't work anymore. I have fontBaseDirs for several languages that look like this (relative to baseDir): ../../../config/ru But if I put it like that in userconfig.xml, FOP complains about the missing protocol. This shouldn't be an issue, but OK, I change it to: file:../../../config/ru Now the resolver seems to eat the first four dots (waiting until it encounters two slashes?) Well, as I remember from my read of the related RFC, the trailing double slash in the protocol in a URL string is not optional, so the above URL is 'erroneous'. What the resolver probably could do in this case is much like what any decent browser does when you type 'http:www.some-site.net', and append the double slash to the protocol string, so the URL would eventually become your intended result file://../../../config/ru/ It seems like it depends on how you extract the protocol string from a given URL. Do you wait for the two slashes, or stop at the first colon and then check whether two slashes immediately follow and insert them if necessary? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use a relative URI in the config file (in 'renderer/fonts/font/@embed-url')
"J.Pietschmann" wrote: > /[EMAIL PROTECTED] Temporary hack to compile, improve later */ > return new java.net.URL(uri).openStream(); > Don't expect a quick fix,Getting the necessary information > for resolving relative URLs at this point will need some > work. Ok, thanks for pointing this out. I'll look for an other way to achieve my goal (I unfortunately don't know FOP enough to try to contribute here). Regards, --drkm ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use a relative URI in the config file (in 'renderer/fonts/font/@embed-url')
Hi all, > FOP 0.91 currently can't deal with relative URLs for embedding. Neat > comment in the relevant code: > /[EMAIL PROTECTED] Temporary hack to compile, improve later */ > return new java.net.URL(uri).openStream(); > Don't expect a quick fix,Getting the necessary information for > resolving relative URLs at this point will need some work. > > [snip] >> I tried to use "file://../", "file://.././", etc., but no one works. > > Neither of these two is an relative URL, as you might have thought. I haven't tried 0.91 yet, but in 0.20.5 the above URLs did work as relative (although indeed they shouldn't). Worse: if you left out the //, they didn't work anymore. I have fontBaseDirs for several languages that look like this (relative to baseDir): ../../../config/ru But if I put it like that in userconfig.xml, FOP complains about the missing protocol. This shouldn't be an issue, but OK, I change it to: file:../../../config/ru Now the resolver seems to eat the first four dots (waiting until it encounters two slashes?) and looks in ../config/ru, which doesn't exist. To make FOP find the dir, I can specify this: file:../../../../config/ru (notice the *extra* ../) or even this: file:./../../../config/ru or this: file://../../../config/ru There's also something wrong at the other end: if the location isn't found, the "/ru" part will be left out of the "not found" message. If I put a slash at the end, this doesn't happen. So, to wrap it all up, in order to have FOP look for my metrics files in ../../../config/ru *and* give me the right error message if it doesn't find them, I have to specify the fontBaseDir as: file://../../../config/ru/ BTW, there seems to be a similar (though not exactly equal) problem in Ant. All that said, let me also make clear that I love FOP and that I HUGELY appreciate the efforts of all you people who brought it to us and are working hard to improve it. Without Apache FOP, the Firebird open source project would have no PDF documentation, or at least we would be dependent on individuals who had the money to buy a proprietary FO processor and the time and kindness to build our docs. Now every project member can build great-looking PDFs, using only open-source tools. Thanks! Greetings, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use a relative URI in the config file (in 'renderer/fonts/font/@embed-url')
Florent Georges wrote: I have a little trouble to use a relative URI in the FOP config file. FOP 0.91 currently can't deal with relative URLs for embedding. Neat comment in the relevant code: /[EMAIL PROTECTED] Temporary hack to compile, improve later */ return new java.net.URL(uri).openStream(); Don't expect a quick fix,Getting the necessary information for resolving relative URLs at this point will need some work. [snip] I tried to use "file://../", "file://.././", etc., but no one works. Neither of these two is an relative URL, as you might have thought. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding PDF documents?
On Jan 6, 2006, at 10:15 AM, Glen Mazza wrote: I think we're talking two different things. FOP's input is still an XML document in the XSL namespace, those types above are graphics incorporated via fo:external-graphic or fo:instream- foreign-object. You would apparently like a new extension element then, possibly under fo:instream-foreign-object, that will allow for incorporating a PDF document. PDF is not a graphic though. It is an output type, a document--so I guess you would need to write a parser for FOP to be able to translate the PDF document into XSL-namespace events that can subsequently be rendered on FOP's standard output types--PDF, PS, AWT, RTF, etc. That is out of scope for FOP. But if someone wanted it to contribute it to FOP, I would defer that to the rest of the team (I haven't been coding for awhile), but it would need to be pretty robust and solid -- not just a partly working system that will fill up the Bugzilla list with errors from people trying to use FOP just to concatenate PDF documents, or to convert PDF documents into other output formats. (Then again, that's how open source works... ;-) While it would be 'nice to have' I'm not convinced it would be a good idea. It would be one more maintenance 'hassle' to support & maintain (unless this new addition had enough of a following to support it-- i.e. new developers). BTW, although TIFF files are supported, I don't believe multiple page TIFF files (e.g., FAX documents) are supported. I took a look at the FOP Graphics page's TIFF section ([1], [2]) & didn't see any mention about it, but I believe that only single-page TIFF files are supported. Also, AFAICT the W3C XSL Working Group does not allow for embedding XSL documents within other XSL documents (i.e, placing an fo:root within an fo:root). Whatever their philosophical concerns are about such embedding may also be relevant for embedding PDF documents here. Glen [1] http://xmlgraphics.apache.org/fop/0.20.5/graphics.html#tiff [2] http://xmlgraphics.apache.org/fop/0.91/graphics.html#tiff Web Maestro Clay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to use a relative URI in the config file (in 'renderer/fonts/font/@embed-url')
Hi I have a little trouble to use a relative URI in the FOP config file. Here is an excerpt: I got the following: pdf.Failed to embed fontfile: ../fonts/arial.ttf(URI could not be resolved (no protocol: ../fonts/arial.ttf): ../fonts/arial.ttf) I tried to use "file://../", "file://.././", etc., but no one works. The only one that works is an absolute one, but I really can't use this. Any idea? PS: I use FOP-0.91. Regards, --drkm ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding PDF documents?
David Elliot wrote: Hi Glen, Sure that makes sense, FOP looks to be conceived as an Apache strength XSL-FO -> PDF formatting utility/library that implements W3C's XSL-FO standard - the end result being a library which task specific applications can then confidently leverage. Although, currently FOP supports a variety of input formats - notionally image/graphic data (BMP, EPS, GIF, JPEG, PNG, SVG or TIFF) - for inclusion during a render. Did this list of supported data formats evolve via contribution, or is it strictly specified by standard ? Many thanks, David I think we're talking two different things. FOP's input is still an XML document in the XSL namespace, those types above are graphics incorporated via fo:external-graphic or fo:instream-foreign-object. You would apparently like a new extension element then, possibly under fo:instream-foreign-object, that will allow for incorporating a PDF document. PDF is not a graphic though. It is an output type, a document--so I guess you would need to write a parser for FOP to be able to translate the PDF document into XSL-namespace events that can subsequently be rendered on FOP's standard output types--PDF, PS, AWT, RTF, etc. That is out of scope for FOP. But if someone wanted it to contribute it to FOP, I would defer that to the rest of the team (I haven't been coding for awhile), but it would need to be pretty robust and solid -- not just a partly working system that will fill up the Bugzilla list with errors from people trying to use FOP just to concatenate PDF documents, or to convert PDF documents into other output formats. (Then again, that's how open source works... ;-) Also, AFAICT the W3C XSL Working Group does not allow for embedding XSL documents within other XSL documents (i.e, placing an fo:root within an fo:root). Whatever their philosophical concerns are about such embedding may also be relevant for embedding PDF documents here. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
