These are your requirements for FOP. Most other users don't have these requirements so there's no focus in this direction. Yet, anyway. Giulio, you're invited to help us improve FOP. Everyone can participate. It would be great to have someone who really cares about the AWTRenderer/PreviewPanel. AFAIK, it's not something that is used by any of the active committers. It was introduced once, improved a little over time but it's still just a minimal viewer. I'm sure at least some level of interactivity would be relatively easy to implement.
On 10.01.2008 15:32:16 Giulio Buccini wrote: > > 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. Uhm, in your real-world application anyway. Do you know how many users use FOP in real-world scenarios? > 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. The project is defined to produce a formatter, not necessarily a document viewer. The AWT Viewer is just a goodie we've got somewhere on the way by a contributor. It's not a central part of FOP. > 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? Sorry, but I don't follow you here. > 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? Sure, that would be cool. But we're struggling enough to cover enough of the XSL-FO specification in the first place. The question is: Can you help us? > 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. The preview is so special and not in wide-spread use that there's is not a big set of examples. You'll have to figure out how things work from the source code. Start from the command-line (-awt parameter) and find out how the preview is constructed. It would be great if you document your findings on FOP's Wiki. > I hope in future, FOP project, will go in the right direction: more > usability, sophisticated high-level APIs, details hiding. Unless you put your energy in this, I don't think it will. Sorry. Open Source is developed in the directions the development team steers it. And you can be part of it. > 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] Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
