Hello again, Jeremias, I know: I wrote about MY requirements from MY point view... probably everyone have a different view about that and is pretty impossible to make everybody happy. I understand this...
I have designed many informative systems for big companies and "integration problem" was always the main obstacle in developing: many standards, many technologies, too many formats. I have used Java SE/EE deeply couse of the uniform approach and technology integration it offers. When you work to automatize the business workflow of a large office (for example a Telecom company department) believe me: you will produce a big mountain of documents, reports, tables and so on and you must take care about a detail every forgot from technicians: the HCI - human computer interface - this is one of the main factors that make a computer system usable and friendly for the users. Microsoft Word is massively used inside big organizations, and the base concept is WYSIWG. So, if you develop a desktop application for an employe you will receive the -unsolited- question: why what I see on the screen is not what I see when I print document or when I send it by email? Why application cannot show me the final result "in real time" when I work on data? Word is doing that! (I cannot describe my face in similar situations... when I was working for SIEMENS this was one of the most frequent questions...) But I think people are right: documents are not for technicians like you and me, documents are for people. Must be readble, well formatted, colored and attractive. XSL-FO offer all instruments to create beatiful documents but... you cannot easily integrate them in a desktop application. I have used yet FOP during my work, and it was always the final step after a lot of elaboration: the printing/email step. Batik project offers a big support for application integration: the JSVGCanvas class and the SVGGraphics2D generator class. iText offers something similar for PDF... so I think my requirements are not so much far from the "real world". I was seriously thinking to be involved in the enhancement of the AWTViewer, but for now I have no time at all. I can imagine the big effort caming from the implementation of the XSL-FO specifications... I absolutely understand you; but, as I repeat, for now I cannot be involved in the FOP project even if I like your proposal very much. Maybe in a close future... who knows? Anyway, thanks for your sincere opinion and suggestions. Giulio Buccini Jeremias Maerki-2 wrote: > > 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] > > > ----- Giulio Buccini -- View this message in context: http://www.nabble.com/How-navigate-scroll-inside-the-PreviewPanel-tp14515390p14741182.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]
