tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [OT] Console when running as a service.
Date Mon, 11 Mar 2013 20:06:00 GMT
Mark Eggers wrote:
> On 3/11/2013 11:20 AM, André Warnier wrote:
>> wrote:
>>> On 11 Mar 2013, at 14:21, "André Warnier" <> 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:
> 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:
For additional commands, e-mail:

View raw message