Hi Andreas, I have read your reply with great interest, I subscribe all you wrote. Nevertheless, there is a little point: I don't want to integrate a wordprocessor-like application (like Microsoft Word); I was only stressing on one point, the WYSIWYG methapore. Today, customers are more smart and pretends more from software application. As I understand, today you cannot show an application in the MS-DOS style to your customer. Customer wants more and pretends more. The point is that many office-automation application are today using the WYSIWYG metaphore deeply, and Microsoft Word (that I hate) is one of the first to brings this concept on the desktop of milions of user.
Ok? I don't want a PDF word processor at all. My requirements is more simple: bring this concept as valid for XSL-FO (or pdf) documents too. Understand me, Java swings is great, but it help you until you stay inside the confortable view of your own application; but, when you try to export graphic contents outside of the application-box you start to become hungry: what you get is always different from what you see on the screen. Obviously I'm not speaking about simple graphic contents (one image, one diagram, one little text paragraph). I'm speaking about long, hierchical, complex documents. This kind of documents needs a more sophisticated management: they needs to be organized, styled, refined to allows the user to understand if that big amount of information will be well-understood when exported (for example to the boss of a department). Of course, you can do all the work by yourself, arranging contents with swing components or even with the Graphics2D object. Nevertheless, the effort is enormous: margin, pagination, borders, fonts... wao! The question is: why I must do all these work when there are tools that are specialized on this kind of work? The drawback is that that tools (FOP) are not easy to integrate in your desktop application. And that's all. FOP is a great transcoder: from XSL-FO to PDF (not only). My point of view is different: great libraries like FOP are reduced in usability if there is no another tool for easy integration close to them. I'm stressing the desktop-application integration point: in this case - and from my point of view - this aspect increases the FOP usability in a tremendous way. As you told, PDF format has become "ipso facto" a standard for exchanging documents. The quality of that docs is impressive. It will be fantastic if programmers can "show" this quality on the screen of their users. Believe me: many times (maybe all times) long documents (with a lot of data) was not understood by the audience cause of lack in presentation. It will be great if java programmers can bring the powerful of pdf data presentation to their customer. Allows me a last point: when you wrote about an hypotethical XSL-FO editor you still are thinking from a tecnical point of view. You think to an editor like something for "real" programmers, the pepole appasionated in writing any detail, even every single byte of code. In my point of view, a real useful XSL-FO editor is something completely different from your idea: is graphical tool that allows the user to set the general structure of documents (colums, borders, flow of text across pages, and so on) and after this.... generate the parameterized xsl-fo code by himself! A real XSL-FO editor mast save user to be bored from all XSL-FO stuff/details (I think) . It's fantasy? I believe not... computer must be used to simplify our life, not to add complication... regards, Giulio Buccini. Andreas L Delmelle wrote: > > On Jan 10, 2008, at 20:00, Giulio Buccini wrote: > > Hi Giulio > >> 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... > > Of course, but it is always interesting to see those different views > posted here. > Who knows, maybe other users have similar thoughts/needs, but have so > far refrained from speaking up (since they already knew, more or > less, what the answer would be). > >> <snip /> >> 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...) > > Sure, and OpenOffice has a word-processor too, and it's also > completely free of any charge. > The big difference with XSL formatters, is that they are not word- > processors, but should rather be compared to web-browsers. A WYSIWYG > XSL-FO application would be much more like an HTML editor, and AFAIK, > in most HTML editors, you don't really edit the page on-the-fly. You > alter the source code, and the document is re-rendered using as much > cached information as possible. > > Another huge blocker is that the transformation is far from always > easily reversible. Creating /the/ XSL-FO source for a given PDF > document is impossible, unless the PDF would contain a reference to > it. For a given printed layout, there are always at least a handful > of ways to describe/define it in FO. An XSL-FO document is more > comparable to Tex than to Word's .doc. > > Looking at PDF in particular, PDF editors are also not word- > processors. You cannot create a blank document, or alter an existing > one, in the same sense as you would with Word. iText, for example, > mentions in the manual somewhere that you cannot really replace text > in the PDF using the iText API, but you would have to create a new > text box containing the replacement and place that over what needs to > be replaced. (If I recall correctly... it's been a while since I read > that; maybe this has already been changed in the meantime) > > PDF is, OTOH, probably *the* most suited format for getting a uniform > result whether viewed on the screen or printed on paper. > >> >> 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. > > That depends on what output format you choose. If you choose RTF, > then you /can/ edit the end result in MS Word, but you have the > downside that RTF is not 'Rich' enough to cover every aspect of the > Recommendation, and due to that, we're again stuck with the > impossibility to create /the/ XSL-FO document corresponding to /an/ RTF. > >> 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". > > Indeed, but I think the point is more: > If one needs a word-processor -> Word or an OO-spinoff > If you need a WYSIWYG PDF editor -> Acrobat or ...? > If you need a WYSIWYG FO editor -> Altova, oXygen, Scriptura come to > mind. If I recall correctly, they all integrate FOP in some way... > some do it merely by initiating a batch process, but it is possible > to use only parts of FOP, if one wants. > > You are definitely right, that the public API is somewhat limited > ATM, and the rest of the source code is currently not very friendly > unless you spend quite a bit of time familiarizing yourself with it. > There is no easy way to access elements of the FO document on the > controller layer, as it were. FOP's design is currently based on > whole-document transformations. We would need quite a bit of changes > to perform a 'live' atomic re-rendering of a fo:block that is being > edited, for example. > > Currently, there is no completely free FO editor (IIC). Only > commercial implementations, using a free XSL formatter in the > background. > >> I was seriously thinking to be involved in the enhancement of the >> AWTViewer, >> but for now I have no time at all. > > That's unfortunate to hear. > >> 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? > > If so, be sure to direct all your questions/suggestions regarding the > source code to [EMAIL PROTECTED] > >> >> Anyway, thanks for your sincere opinion and suggestions. > > Likewise! > > Cheers > > Andreas > > --------------------------------------------------------------------- > 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-tp14515390p14757378.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]
