tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [OT] Re: Console when running as a service.
Date Mon, 11 Mar 2013 21:25:41 GMT
verlag.preisser@t-online.de wrote:
> Hi André,
> 
> 
> -----Original-Nachricht-----
>> Von: André Warnier <aw@ice-sa.com>
>> An: Tomcat Users List <users@tomcat.apache.org>
>> Betreff: Re: Console when running as a service.
>> Datum: Mon, 11 Mar 2013 19:20:23 +0100
> 
> 
>> +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 ?
> 
> I guess with "proprietary format" you mean the old/outdated .doc format? :)
> 
> This has been superseded (since 2006/2007) by the Office Open XML format which has been
standardized as ECMA-376 and ISO/IEC 29500 [1], for which a public documentation is available,
so I wouldn't call this proprietary. ;-)
> 
> However, you're probably right that a lot of already existing word documents are still
in the old .doc format instead of .docx.
> 

This is still [OT], and I like the subject, so let's elaborate a bit.
The above paragraph responded to an "Eek", so it wasn't really meant as technically accurate.
But yes, by proprietary I did mean mainly the .doc, .xls and .ppt formats (and their 
associated template formats). And yes, there are still plenty of those around.
For instance, we recently processed a customer archive of more than 100,000 documents, in

which there was a mixture of .doc, .xls, .ppt, .docx, .xlsx, .pptx, .pdf, .tiff, .txt and

a few more.
But even if one talks about the supposedly "open" OpenXML formats .docx, .xlsx and .pptx,

I have been unable so far to find any non-MS tool which can accurately process say more 
than 95% of your average collection of such documents without introducing some significant

distorsions in the result, or corrupting or losing some content.  So I have to suppose 
that either of the following is true :
- the published specification is not accurate enough to cover all the cases one finds in 
real-world OpenXML documents
- the programmers who read these specifications are incapable of creating software that 
will accurately handle 100% of the documents which are created in this format
- the people who published this specification deliberately made it obscure so that others

would have trouble interpreting it correctly
- the people who published this specification are deliberately making software that 
creates documents that violate the specification, to make life miserable for everyone 
else, particularly their commercial and non-commercial competition
- the people who published this specification are unwillingly making software that creates

documents that violate the specification through sheer incompetence
- the people who published this specification are making software that creates documents 
that violate the specification, because they just don't care and because they published 
this specification only so that they could claim to support open-source trends and 
non-proprietary standards
- the programmers who read this specification are unwilling to create software that will 
accurately handle 100% of the documents which are created in this format, just to make a 
point about the spirit of open-source and how bad the companies who make proprietary 
software really are

..or more probably, a mixture of all the above.

And the practical result for everyone else it that it is a mess.

But I must add that I am not complaining about it too much, because if it wasn't so, I 
would not have either a product or a job. So please, MS and others, keep on adding new 
features, standards, revisions, versions, interpretations and new software which follows 
them or not, and I will happily spend time cleaning it all up for my bewildered customers.
(And, with a wink but nonetheless a background of seriousness, I would hasard to guess 
that the situation isn't too different when one reflects about Java and Tomcat).





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message