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]
