Re: Newbie question
Hello Dola, I did my homework, but this does not appear to be an FAQ! How does FOP read PDF's? It doesn't, at least not to my knowledge. It reads Formatting Objects files (typical extension: .fo) and *produces* PDF and other formats. Paul Vinkenoog - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Named Destination support in FOP 0.94
Hi Tai, Thanks so much for your help. However, I tried exactly as you describe. It doesn't work for me. The PDF always open at the top of document. I am using FOP 0.94, JDK 5, Windows 2000, Acrobat Reader 8.1, and IE6. Do you have any idea why this is not working? Is that because my combination of software cause this problem? I don't know, but I've uploaded some files that may help you find out: - flowers.fo contains the following named destinations: intro, roses, tulips, daisies - links.fo contains links to all of them (one URI and one GoToR to each destination) I've also added the two PDFs, built here with a freshly installed FOP 0.94 On my system (Win2000, Acrobat Reader 7.0.0, MSIE 6.0, Firefox 2.0.0.6) I get the following results: LOCAL - In Acrobat Reader, the GoToRs work 100% correctly. In MSIE, the GoToRs don't work (this is as expected), the URI links work 2 or 3 times out of ten. In Firefox, I can't open them locally (it immediately asks me if I want to save it or open it in Acrobat Reader). ON THE WEB -- In MSIE, the GoToRs don't work (this is as expected), the URI links work 5 times out of ten. In Firefox, the GoToRs always work (surprise!), and so do the URI links (this time at least). I suggest that you try the generated PDFs both online (http://vinkenoog.nl/test/) and on your local computer. If they don't work for you in Acrobat Reader, it must have something to do with the version (8.1 vs. 7.0.0). If they do work, rebuild both PDFs on your computer and see what results you get then. BTW, I've deliberately placed the fox:destinations in flowers.fo in all kinds of spots, just to show that the location doesn't matter as long as daddy is a fo:block. Of course I don't suggest that you should scatter your destinations all over the place like that in a serious project! Please let us know your results! Kind regards, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Named Destination support in FOP 0.94
I wrote: ON THE WEB -- (...) In Firefox, the GoToRs always work (surprise!), and so do the URI links (this time at least). Playing a bit more with this, I now get all kinds of wrong results (i.e. landings on the wrong dest) with GoToRs in Firefox. Sometimes it jumps to the wrong destination, sometimes it even jumps to a destination if I click on flowers.pdf in the web directory, so it should go top-of-file (I suppose it had the dest cached). Bottom line: don't trust any browser to work 100% correctly with named destinations. Cheers, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Named Destination support in FOP 0.94
Hello Tai Hu, I want to find a way to add a named destination into PDF file by using FOP 0.94. Then later on, I could open a pdf file by pass in #nameddest=named destination on URL to jump to a particular section. I checked 0.94 change history which states that Named Destination support is added for version 0.94. However, I couldn't find any document on how to use it. Could anyone show me an example of usage of this feature? Thanks! Let's say your target document is called flowers.pdf, and you want certain sections to be reachable from outside the document. To do that, first declare this namespace in flowers.fo: xmlns:fox=http://xmlgraphics.apache.org/fop/extensions; And declare the destinations like this: fox:destination internal-destination=intro/ fox:destination internal-destination=tulips/ fox:destination internal-destination=roses/ fox:destination internal-destination=daisies/ Notes: - intro, tulips, roses and daisies must be existing ids in flowers.fo; - the declaration order of the destinations is unimportant, and they don't have to be all together either. Just make sure that each fox:destination is the direct child of a fo:block. Any block will do, it doesn't have to be the block that bears the corresponding id. Now if you build flowers.fo - flowers.fop, the named destinations will be present in the PDF. In the referring document, you can link to flower.pdf's named destinations in two ways: 1) URI-style (using a relative or absolute *URL*): fo:basic-link external-destination=flowers.pdf#tulipsSurf to relative Tulips!/fo:basic-link fo:basic-link external-destination=http://www.nature.com/botany/flowers.pdf#tulips;Surf to absolute Tulips!/fo:basic-link If you're reading flowers.pdf with e.g. Acrobat Reader on your local computer and it encounters this type of link, it will launch a web browser and pass it the URL. The target file will be opened in the browser. 2) GoToR-style (using a relative or absolute *file path*): fo:basic-link external-destination=flowers.pdf#dest=tulipsGoToR to relative Tulips!/fo:basic-link fo:basic-link external-destination=/home/sharon/flowers.pdf#dest=tulipsGoToR to relative Tulips!/fo:basic-link GoToRs work via the local filesystem. Acrobat Reader will open the target document itself if the link is a GoToR. GotToRs should not work across the Web, but in practice FOP-built relative GoToRs often did, because of a bug in the source code which generated a URL link instead of a GoToR. That bug has been fixed, so I suppose this feature stopped working in 0.94 (if it didn't, don't count on it to keep working forever). You should also know that web browsers sometimes (Firefox) or often (MSIE) screw up if you add a named destination to a URL. They always open the target document, but they don't always jump to the targeted named destination (however, even if they don't, they do show the named dest in the address bar). A lot of investigation and testing has been done in April/May and the PDF objects generated by the FOP named destination code are absolutely, one-hundred-percentedly compliant with the formal PDF specification. Still these errors occur, but they are very erratic: clicking on the same destination ten times may get you to the right spot eight times and to top-of-document two times. Or the other way round, depending on the browser. Hope this helps! Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Named Destination support in FOP 0.94
Now if you build flowers.fo - flowers.fop, the named destinations will be present in the PDF. Sorry, I meant flowers.fo - flowers.pdf of course. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lines not breaking with zero width space characters inserted
Hi David, I re-inserted the ZWSPs in your XSL-FO table (they didn't survive the message transport, but it's obvious where they had been), included it in a small test file, built the PDF and the line wrapped nicely after one of the underscores. When I removed the ZWSPs again, I got an overflow. It didn't make any difference whether hyphenation was on or off. This was done with a home-built FOP, based on the trunk as it was around May 15th. Repeating the exercise with FOP 0.93, I got an overflow regardless if there were ZWSPs present or not, but only if hyphenation was on. With hyphenation off (and ZWSPs present, of course) everything worked fine with 0.93. So if you want hyphenation on and functional ZWSP-breaking at the same time, the solution is to upgrade to the current fop-trunk. Hope this helps! Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lines not breaking with zero width space characters inserted
Hi David, I have looked at the threads relating to line break issues as well as looking at various documentation on how to force line breaks. From what I have read, it appears that inserting a zero-width space character in a long string should enable the string to be broken at the ZWS character when it spans a column edge (in my case, a very narrow table column). I have succeeded in inserting various kinds of breakable characters after underscores (which are common in the strings I'm trying to break). However, the only character that actually causes a break is a full space character, #x0020; . Other characters I've tried include the ZWS U+200B, soft hyphen U+00AD, and hair space U+200A -- but these do not appear to enable line breaking for me. I am using FOP 0.93 in a Windows environment. I'm also using an en-US hyphenation table from OFFO. What I would like to find out is: 1. Should the ZWS work, and if so, what might cause it not to work? ZWS U+200B should definitely work - I use it all the time. However, I've done some work on this a couple of months ago and I discovered that they don't work as potential line breakers if you wrap them in a fo:character instead of inserting them directly into the string. So if yours are inserted via fo:characters, change your setup. Second, are you sure the ZWSPs end up correctly in the XSL-FO file? Have you actually seen them sitting there, with an editor that can detect them? Third, there were some ZWSP-related problems if you embedded fonts in the PDF (as opposed to using a standard font). These exist in FOP 0.93, but have been fixed in the trunk. So that's another thing you might try. 2. Are there alternatives for creating a line-break after an underscore? Beyond the things you mention, I wouldn't know (not that that says a lot). But it _must_ be possible to get the ZWSPs to work, so let's try that route first. If the above suggestions don't help, you might create a small XSL-FO file that doesn't work for you and let me and/or others try it. Cheers, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: collapsing PDF bookmarks
Hello Andreas, Home, checked, yes: FOP fully supports the starting-state attribute (show or omit to expand, hide to collapse). Interesting. I haven't needed the feature myself, so was unaware that this was implemented. Just one question: is this already true for FOP 0.93, or only for Trunk? I just gave it a try with 0.93 and it's fully functional in that version. Greetings, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: collapsing PDF bookmarks
Hi Jeff, By default, when you use FOP to generate a PDF file, the bookmarks in the file are expanded. I'd like to collapse the bookmarks. In the FOP FAQ (http://xmlgraphics.apache.org/fop/faq.html#pdf-bookmark-display), it says that FOP doesn't currently allow you to control bookmark display. I'm not so sure if that's still correct (not home right now, so I can't check). I think if you set the starting-state=hide attribute on a fo:bookmark, FOP will nicely render it as initially collapsed. Notice that hide is a little misleading: the bookmark itself isn't hidden, only its children are. Please give it a try; chances are that you won't need any post-processing tools. HTH, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: collapsing PDF bookmarks
Hi again, (http://xmlgraphics.apache.org/fop/faq.html#pdf-bookmark-display), it says that FOP doesn't currently allow you to control bookmark display. I'm not so sure if that's still correct (not home right now, so I can't check). I think if you set the starting-state=hide attribute on a fo:bookmark, FOP will nicely render it as initially collapsed. Home, checked, yes: FOP fully supports the starting-state attribute (show or omit to expand, hide to collapse). Cheers, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93 is not resolving empty fo:inline index markers
Hello Jeff, I'm using DocBook XSL 1.7.2.0 with FOP 0.93. When I generate a PDF, the indexterm elements have extra whitespace (from line breaks and tabs). I successfully removed the whitespace by editing one of the DocBook stylesheet templates. However, the page numbers in the index are missing. Also, FOP warns about unresolved ID references, such as this warning: WARNING: Page 9: Unresolved id reference d0e127 found. When I open the FO file, here's what one of the index entries looks like: fo:block xmlns:fox=http://xmlgraphics.apache.org/fop/extensions;Administration Console, fo:basic-link internal-destination=d0e127fo:page-number-citation ref-id=d0e127//fo:basic-link/fo:block Here's the internal destination it's pointing to in the file: fo:inline id=d0e127!--Administration Console--/fo:inline I suspect that the inline is dropped because it has no content. You can verify this by inserting a zero-width space (200B hex) after the opening tag and rebuilding the PDF. If it works for that destination, you can change the indexterm template so it will generate these ZWSPs automatically. If it doesn't work, let the indexterm template generate wrappers instead of inlines and switch to fop-trunk (FOP 0.93 drops empty wrappers, but the trunk version keeps them if they have an id). The missing page numbers are another thing. I had a similar (but not the same) problem with FOP 0.20.5, which was caused by the fact that the basic-link element had no content other than the page-number-citation. This too was solved by inserting a ZWSP (my template inserts it after the page-number-citation, but I suppose it works just as well if you place it before). I hope this helps you a little in finding a solution. Kind regards, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fo:bookmark external-destination support
Hi John, I am writing to get a confirmation on whether or not the external-destination attribute on the fo:bookmark is supported by FOP 0.93. Note: I am going to PDF... not sure if this is important or not. The error I'm getting in my console is: 37755 [main] WARN org.apache.fop.fo.FONode - Warning(22/770): fo:bookmark, external-destination property not currently supported I have recently worked on the bookmarks code (to improve the *in*ternal targeting) and I can confirm that external-destination support is currently totally absent. It's fairly easy to implement though, and I've been thinking of doing it -- if I find some time before somebody else does ;-) Meanwhile, you'll have to use basic-links for external destinations. Kind regards, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Base URL for loading images
Hi all, When I call fop.bat with -fo input, the base for resolving relative image URLs is the source file's directory. When I call fop.bat with -atin input, the base URL is the parent of the current dir. Is there a special reason for this? (The build used is a late Jan 2007 fop-trunk.) Kind regards, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Typo in AbstractRenderer :: renderBlockViewPort
Hi all,
In fop/render/AbstractRenderer.java, lines 453-462:
protected void renderBlockViewport(BlockViewport bv, List children) {
// clip and position viewport if necessary
if (bv.getPositioning() == Block.ABSOLUTE) {
// save positions
int saveIP = currentIPPosition;
int saveBP = currentBPPosition;
Rectangle2D clippingRect = null;
if (bv.getClip()) {
clippingRect = new Rectangle(saveIP, saveBP, bv.getIPD(),
bv.getIPD());
I suppose the second call to getIPD() should be getBPD(), unless you
want to force the clipping rect to be square.
At first I wanted to report this through Bugzilla, but the Getting
Help page stipulated that it should be raised at the user list first,
so here it is.
Kind regards,
Paul Vinkenoog
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Typo in AbstractRenderer :: renderBlockViewPort
Hello Andreas, At first I wanted to report this through Bugzilla, but the Getting Help page stipulated that it should be raised at the user list first, so here it is. Well, in fact this is slightly off-topic here, and belongs more on [EMAIL PROTECTED] That's what I figured too, but being a relative newcomer I decided to follow the published guidelines to the letter :-) Ultimately, the quality of FOP depends greatly upon users like yourself, who are not afraid to take a stroll through the code, The reason I looked at the code at all was that I wanted to re-implement the full internal link behaviour (landing on the exact spot, that is). I've got it working now, need to iron out a few wrinkles and then I'll bring it up on fop-dev. I hope it's usable for the project too. Kind regards, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: zero width space displayed in pdf file
Hi all, I have some problem with zero width spaces they occur in PDF file generated from fop file. fo:inline font-family=MSMincho font-size=10pt text- align=startWork#x200B;day/fo:inline I just tried with FOP trunk, and with a Base14 font this problem can't be reproduced, so I'm guessing this is caused by the fact that the font(s) in question have a glyph for this character...? I can also confirm what lecki reports. In our project we use FOP 0.20.5 to produce PDFs in several languages. In Western and Cyrillic script there's no problem with ZWSP 200Bh (except that they are sometimes stretched for justification purposes, which we don't want). In Japanese (MSMincho) they appear as full spaces. Kind regards, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: zero width space and FOP
Hello Fabrizio, I've asked the translators to insert zero width spaces in Unicode. All the properties file are UTF-8 encoded. They tried inserting zero width spaces as they know how, but up to now it doesn't seem to work. Has any one ever tried to insert zero width spaces into a properties file and use it to create a PDFs? I'm not sure what you mean with properties files but I have written XSLT templates that insert zero-width spaces which I specify as: #x200B; After transformation, they wind up as UTF-8 encoded zero-width spaces (Unicode 200B hex) in the .fo file. FOP 0.20.5 handles them correctly, breaking lines at such spots if and where appropriate. The only thing I dislike is that it also uses the ZWSPs to insert whitespace for line justification. I know the standard allows this, but I wish there was an option to turn that behaviour off, because it pulls apart path elements, URL components etc. Greetings, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop missing Ant?
Hello Jeremias, Something doesn't feel right here. FOP 0.20.5 DOES bundle Ant 1.5.1 (found in the lib directory). That's strange - I have a FOP download here (fop-0.20.5-bin.zip) and there's definitely no Ant inside. Afaict I made the download on 10 Jun 2004. All the files are timestamped 15 Jul 2003 4:04. Greetings, Paul Vinkenoog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop missing Ant?
Hi Sir Strongbad, I just downloaded FOP 0.20.5 and I am trying to run the servlet example and I am getting an NoClassDefFoundError error. When the build.bat runs, it references a JAR called Ant-1.5.1.jar under the lib directory. When I go to that directory, there is no Ant-1.5.1.jar file present. I have read in several places that the Ant-1.5.1.jar should be packaged with FOP. What's the deal? I know I am overlooking something. No, you're not. FOP 0.20.5 does not come with Ant. You have to get that separately at http://ant.apache.org. You may also have to download some of the other tools. BTW, the build.bat references really old lib versions. You need to change the filenames to match what you download (the names don't usually include version numbers). Good luck, 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')
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]
