Mark Eggers wrote:
On 3/11/2013 11:20 AM, André Warnier wrote:
p...@pidster.com wrote:
On 11 Mar 2013, at 14:21, "André Warnier" <a...@ice-sa.com> wrote:
So if for some scenarios, it would be useful to use say MS-Word to
produce a PDF version of a document, it is not possible (or very
difficult) to trigger
this from Tomcat when running as a Service.
Eek! Eek I say!
+1. Eek, I tearfully and shamefully agree.
But still 90% or more of corporate internal documents are written as
Word documents, and there is no open-source tool which can perfectly
handle this shamefully proprietary format and convert it to some
non-propietary format that one could still read in 10 year's time, so
what is one to do if one wants to get some money to get one's children
through computer school and pay for their iPhones, he ?
Sigh, I agree if your constraint is "perfectly" then you're pretty much
stuck. However, even Microsoft doesn't deal with their formats "perfectly".
Marking this OT now, because we are deriving significantly from the OP's
original question.
My definition of "perfectly" in this case, is "pretty much undistinguishable from what the
user himself would get if he told MS-Office : save this MS-Office document as PDF".
For 95% of MS-Office documents, OpenOffice for instance (which is no problem to run inside
a Service context) will do a very good job. Unfortunately, there are 5% of documents for
which it will produce something of which the look (and even sometimes the content) differs
significantly from the original document, and from the same PDF produced by MS-Office
itself. And 5% of hundreds of documents per day is a large number of documents.
For some users and some documents it doesn't really matter all that much, but for some
others it does. So again, it depends on the exact circumstances.
We have a similar issue with PDFs. There are umpteen libraries out there which create
PDFs, some of them better than others. Some of them produce PDFs which are really buggy -
in the sense of really not respecting the published PDF specification. But they can still
be opened by the Adobe Acrobat Reader, which is the reference that most users refer to
("If I can open it with Acrobat, then it's a correct PDF"). This is basically wrong,
because the Adobe Acrobat Reader is rather tolerant, and will open and display some PDFs
which are obviously sloppy. But it forces us to also create tools which can read and
process such sloppy PDFs, and maybe thus accept a PDF which the next generation of readers
won't be able to open.
Sigh. Sometimes being correct and abiding by the rules conflicts with being practical, and
one has to navigate between them as judiciously as possible.
An alternate solution (which I've not played with in a very long time)
could be:
http://poi.apache.org/
This could remove the requirement for interacting with a desktop
application when dealing with some Microsoft formats.
Thanks, I'll have a look at it (maybe again).
There exist a number of such alternatives. Some are better for some documents, worse for
others. And over time, some get better and some get worse (slower development, do not
keep in sync with new document versions). We are always on the lookout for the best
alternative of the moment, and try to structure our applications so that we can switch the
tools we use without too much fuss.
It is always a bit like walking along quicksands though, because the variety of ways in
which people manage to screw up real-world documents is amazing; and because in all
document formats, there is always this "feature creep" which developers seem to be unable
to stop themselves from falling for.
So you have to spend a considerable amount of time on testing over a large volume of
documents before you can really accept any tool as "good enough".
All of this to say that using an (MS or other) desktop application is not the way we would
prefer to do things, but that since it is the reference used by our customers, we are
sometimes forced to do this. And since some of these applications do not exist in a
version that can be used without problems in a Service context, we sometimes have no
better choice than to run the application using it, as a desktop application itself.
Which after all and roundabout, brings us back to the original OP's question.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
