[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: M$ Word filter?
From:       dep <dep () snet ! net>
Date:       1999-11-26 6:10:02
[Download RAW message or body]

On Thu, 25 Nov 1999, Keith Antoine wrote:

|All the koffice stuff is ALPHA and no way is it finished, I am led to
|believe from their list that the kword will read word docs, when its
|released

my sense, alas, is that we're not gonna see a word filter unless
someone undertakes the immense and miserable task of writing one. i
don't think there's a winword filter anywhere that works with 100
percent reliability -- hell, documents don't even freely pass between
copies of the same version of word on different machines. the best
i've seen is the one in staroffice, and it misbehaves if the writer
of the document has availed himself of the feature bloat of word,
with those awful little yellow flags and other nonsense. remember,
too, that msft keeps moving the target.

a better idea, i think, would be for linux folk and others outside
microsoft to establish a common document format for word processors.
there are close to a dozen half-done linux word processors, from
maxwell to papyrus to siag to abiword, and much of the problem is
that they don't any of them talk to each other. kword's native
format, unless i'm mistaken (and i very much hope i am) will be yet
another one alien to everything else. staroffice has its own native
format, as do applix and word perfect, though word perfect's format
has been around for so long it's a little difficult to quibble about
it.

some have suggested rtf, which might be fine, though it leaves a lot
of stuff out of documents that ought to be in them, such as graphics,
and among the word processors mentioned above, few will properly
import each other's rtf files.

what's needed, then, is a format that preserves character formatting,
of course, and that at time of export -- let's presume that we're not
talking a native format at the moment, though i'd favor it as a
native format -- grabs graphics and the state of embedded links --
live links to spreadsheets, for instance -- at the time of export and
saves the data in the document. yes, at that point the link is broken
unless the program opening the document discovers that the link
exists; if not, it falls back on the data packed with the doc. the
disadvantage here, of course, is that storage requirements would be
increased and transfer times would be greater. i don't know of
anything that prohibits gzip, zip, ot bzip2 from being invoked as
part of the process, if storage is an enormous concern; otoh, storage
is not exactly expensive, and today one can xfer a 500k doc in less
time than it took to xfer a 50k document not many years ago.

the establishment of such a standard would produce a worthy
alternative to the microsoft-imposed standard. but for it to succeed,
it would need to be supported by a wide variety of word processors
for linux and other platforms. i see no evidence of that happening; i
see little evidence of a winword filter that works reliably, either.

-- 
dep__________________________________________________________________
                2000 is a number that breaks computers.
                01-01-01 is when the millennium begins.

[prev in list] [next in list] [prev in thread] [next in thread]