Hello Jeremias, I apologyze, you're right: PreviewPanel is a renderer of the FO document, not of the PDF document.
Nevertheless, as I understand, FOP was designed mainly to realize a software the is used mainly in off-line mode. Beleive me, FOP is great, but it cannot be used easily for integration in real-world application. The main lack of FOP is the follow: it doesn't provide API to manipulate and support interaction with a user. I adore FOP, but it can be used only in pipe-processing, scriptings, batch and so on. I think there is a lot of people (like me) interested in a easy-to-use API to develop real solutions using the XSL-FO standard. From my point view FOP is too much close to a "compiler" (!!) : give-it the XSL-FO code and it will give you something useful (PDF for example). The point is: java is powerful language and it allows sophisticate levels of abstraction, so why I must code XSL-FO directly? I think that the major part of people is using FOP as a sort of transcoder routine. Understand me, this is a big result di per se, but I think more success can be achieved if FOP is completed with a set of useful software tools for composition, manipulation, interaction, browsing and so on. Do you agree? Even SVG is supporting features like a simple mouse-click... Returning to your point, there are not so much free PDF viewer implemented in Java. Most of them are becomed commercial products while the others are really poor and bad implemented. I have adopted the JPedal Standard implementation (the one that is free): no documentation but a terrible simple application used as reference for free-users (it seems like an old old old old C code translated in java - can you imagine what a mess?? Mamma mia!). I'm doing on the PDFDecoder class of JPedal exactly the same kind of work that you have suggested for the AWTRenderer: a lot of heavy personalization and implementation of basic user features (goToPage, scrollToBokkmark, zomm in/out and so on). Maybe was better trying to personalize the AWTRenderer, but main problem is lack of documentation: I have no-idea on how the AWT renderer is working internally; there is no a code example or a simple application. So I don't have a minimal base for starting implementation. I hope in future, FOP project, will go in the right direction: more usability, sophisticated high-level APIs, details hiding. Sincerely, Giulio Buccini. Jeremias Maerki-2 wrote: > > Just a second, I think you're mixing things: PreviewPanel is not a "PDF > view". It's displaying the rendered document using Java2D/AWT. The PDF > format is not involved at all. > > To your problem: If you switched to PDF (instead of PreviewPanel), i.e. > embed a PDF-capable browser (or Acrobat Reader directly) in your Swing > application you could make use of PDF named destinations like the > anchors in HTML. This is done using the fox:destination extension > element (which I just noticed is not documented anymore although it has > been reimplemented in the latest release, but I'll fix that right away). > > How a browser or Acrobat Reader is embedded in a Swing application I > can't tell you off-hand but I'm sure there are solutions on the web > somewhere. I've done it in SWT once where it's certainly easier. But the > whole thing could become platform-dependent that way which is bad. > > So the platform-independent solution would be to teach the AWTRenderer > (which is used to display the rendered document in PreviewPanel) to > process the named destination elements to keep a list of the > anchors/named destinations. You could then let the PreviewPanel jump to > the right place. > > I hope that gives you a few first pointers where you can go. > > On 27.12.2007 17:37:27 Giulio Buccini wrote: >> >> Hi, >> >> I'm developing a java stand-alone application structured on the screen as >> follows: >> >> 1) a tree data structure on the left side of the screen (a JTree >> essentially); >> >> 2) a pdf view of tree data on the right side of the screen. >> >> My target is to provide a clear view of the final pdf document to the >> user. >> FOP code is re-generated after any data modification (add, remove, edit >> and >> so on) operated on the tree. >> >> I'm migrating my application from an HTML view to a PDF view cause of >> terrible troubles rising up when HTML is printed on a A4-size paper. >> >> As I understand, the only component that I can use to embed a PDF view in >> my >> application is the PreviewPanel. Nevertheless, this component is very >> limited: user can only jump across pages. >> >> What I need is a trick or a workaround to implement following behaviour: >> >> "When user click on a element in the tree the preview panel automatically >> jumps to the right page and scroll to right place." >> >> Somebody knows a workaround to make this possible? >> >> In my old html-version of my application I have solved this problem by >> inserting many hidden anchor elements in the HTML code and using the >> "scrollToLink" method of the JDesktop pane component. Now I'm in troubles >> cause I cannot apply the same solution with the generated pdf document... >> >> Suggestions? Ideas? >> >> >> -- >> View this message in context: >> http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14515390.html >> Sent from the FOP - Users mailing list archive at Nabble.com. > > > > Jeremias Maerki > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > ----- Giulio Buccini -- View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14734907.html Sent from the FOP - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
