[odf-discuss] News on MS pluggin

[marbux]

[more]

On 10/15/06, Alex Hudson <alex at stratagia.co.uk> wrote:
>
> marbux wrote:
> > Sorry for the delay in answering. I caught up on my sleep last night,
> > slept a full 12 hours. :-)
>
> :) I can sympathise; I'm jetlagged from the US right now...
>
> > I didn't realize this would be so controversial. Unfortunately, I've
> > got an NDA on my best source of relevant information
>
> Please don't take what I'm saying as being argumentative; I'm just weary
> of ODF supporters making unsupportable statements about OXML. You're the
> first person I've heard saying that there's a translation layer in Office.
>
> If we can't back this up publicly, then we probably shouldn't say
> anything _unless_ we can actually prove it ourselves.



+1

[more]

But - I'm not sure
> you'd need to see the source to prove it; I think we can infer it in
> other ways if someone gets access to Office 12.


IIRC, one of the beta builds is still available for downloading.

[more]


> > . So probably the best I can offer as a public source is a lack of a
> > denial by Brian Jones. See my comments at <
> > http://blogs.msdn.com/brian_jones/archive/2006/09/21/764988.aspx>.
>
> Perhaps - he's also sometimes slow to comment on his blog. I guess we'll
> see.


In fairness I should note that Brian has never responded to any of my
comments on his blog. So I don't draw a lot of meaning from his failure to
respond, although he does seem to respond when he has answers that both will
float and are not inconsistent with the Microsoft public relations line.

[more]

There are kind of pros and cons to both ways of doing it. If you
> translate OXML to binary, then I guess you get roughly the previous
> Office plugin more or less for free (modulo ripping out some advanced
> features). So that could make sense.
>
> Conversely, although there are dataloss bugs in Office, by and large
> Office is (and needs to be) a pretty stable piece of software -
> businesses rely heavily on it.


While I agree it needs to be, I'd disagree that it is. They seem to get the
80 per cent mostly right, but don't worry that much about the last 20 per
cent, or at least they used to. But that's a management issue rather than an
engineering competence issue. See e.g., the well-known Focus Magazine 1995
Bill Gates interview on the reasons Microsoft doesn't (or at least didn't)
fix serious bugs. <http://www.cantrip.org/nobugs.html>. Either way, the
early bugs accumulated and wound up impacting later development. And the
persistence of the bugs from the early DOS Word versions say to me that the
code base is a an accumulation of 8-, 16-, and 32-bit code. Of course,
WordPerfect is too, but that code base has the benefit of far more early
bugs having been fixed promptly. Even so, I've been told by WordPerfect
developers that there are huge swaths of code that they wouldn't touch for
love or money because of the accumulation of bug fix spaghetti code. (It
doesn't help that Corel pink-slipped all of the old WordPerfect Corp.
developers and moved development to Ottawa, with its perennial crop of
recent computer science graduates who work for peanuts to gain an impressive
entry on their resumes before moving on.)

Part of my thinking on the brittleness issue has also been influenced by the
fact that nearly all of the really new functionality in MS Office in the
last few years have come in the form of new, smaller apps with pretty
superficial integration, rather than new functionality being integrated into
the major apps.

So my conclusion of brittleness is largely based on circumstantial evidence,
but that's all that's usually available when it comes to proprietary apps.
In any event, the bottom line is that if you need to  create large, complex
documents, Word is a poor choice. There are simply too many unfixed bugs. If
on the other hand you need only to produce simple documents, Word's "our way
or the highway" design does offer some small advantages over WordPerfect.

[more]

Introducing a translation layer
> introduces another interface where things could go wrong - I would be
> amazed if Microsoft had done that; it's not like they lack programmers.
> And while you have "brittleness" on the part of Office, it seems to me
> you just export the problem to another interface by translating, and
> you're also hoping that _they_ know the binary format well enough to do
> that.


As I mentioned above, I think the brittleness results from management
decisions.  But I have long suspected that another reason is architectural,
albeit somewhat a historical accident.  Word for DOS arrived on the market
about a year after WordPerfect for DOS. But WordPerfect had been developed
earlier for mini-computers, and its main competitors had been the Wang and
IBM Displaywriter dedicated word processors and the electromechanical
typewriter era they displaced.

Although both Word and WordPerfect for DOS borrowed heavily from software
originally developed for the newspaper publishing industry, they differed on
the migration path. WordPerfect was heavily aimed at the office (typewriter
document-like) market and used a streaming code processor that was much more
like punched paper tape typesetting technology. On the other hand, Word's
architecture  was heavily influenced by the first bit-mapped WYSIWYG word
processor, Bravo, developed at Xerox PARC. (In fact, Microsoft hired one of
the Bravo lead developers away from Xerox to work on Word.) Word (and Bravo)
relied heavily on some fairly cutting edge stuff from the newspaper
publishing industry, notably the use of styles and frames to compose entire
areas of type rather than just individual lines of type. (I worked with one
of the earliest commercial area composition typesetting machines, the
Compugraphic ACM 9000.) WordPerfect was much more like the earlier straight
text processors and had no area composition capabilities worthy of mention.

The long and the short of it is that Word was originally designed to be much
more like modern desktop publishing solutions than WordPerfect originally
was, but never achieved anything approaching the flexibility or feature set
of a modern full-blown desktop publishing solution. But Word used area
composition techniques and supported bit-mapped screens from the beginning.
WordPerfect, on the other hand, didn't gain support for those features until
the big redesign for WordPerfect 6.x. (That is, except for a file viewer
feature in WordPerfect 5.x. that produced a graphic preview of what the
document would look like if printed that did not allow editing in WYSIWYG
mode.)

I suspect the big problem for Microsoft was in simplifying the feature set
enough for general usage. What became desktop publishing solutions was
necessarily very complex in use, and was designed for repetitive typesetting
tasks. E.g., it takes a fair bit of knowledge to create a custom style but
the payoff is that you only have to do it once for each repetitive
typographical layout. So Microsoft introduced a default set of styles and
required their use. The ability to create custom styles in Word has always
been pretty limited because Word lacks so many necessary features that are
found in modern desktop publishing solutions.

And with the simplification came inflexibility. As it turns out, the
balance struck for WordPerfect 6.x and later is far more flexible. Styles,
frames, and use of other objects are optional except for a document's
"opening" style; you can always achieve the same effects manually and the
inherit flexibility means there are usually at least five or six ways of
skinning the same cat.

Word, on the other hand, is very inflexible and chances are pretty good that
if you need a capability that is on the wrong side of the 80-20 per cent
divide, you either can't do it or the functionality is buggy at best.

But for whatever reason, Word imposes an object approach on its usage and
WordPerfect doesn't. And I strongly suspect the inflexibility and bugginess
in Word reflects deeper problems in the architecture largely stemming from
the simplified, crippleware-by-design, aproach employed. E.g., Word really
will never be able to do Reveal Codes the way WordPerfect can because there
really isn't much markup in the in-memory Word file.

[more]


> I know people rip on Microsoft for poor code, but those who actually see
> MS code - including the dodgy version of Windows 2000 which made it out
> onto the net - seem to say it's generally very good. While Office is
> undoubtably a huge pile of code, I would bet it's in better shape than,
> for example, OpenOffice.org.
>
> I'm not far enough along with OOo to pronounce on the comparison. But it
would have to be pretty bad to exceed Word's bugginess. My big regret with
OOo so far is that its designers tried to mimic the market leader rather
than building the proverbial better mousetrap.
It would really be fun to work on an open source word processor that is
designed to fulfill user needs rather than to replicate the Microsoft Word
experience.

Personally, I believe the days of the giant office suites are numbered. With
open file format standards we should be moving into an era of smaller, more
special-purpose applications rather than more apps built upon apps. I think
Microsoft management shares my belief else we would long ago have seen an
Office redesign from scratch.

That belief is why I devote so much time to exploring ways to minimize the
application componentry framework needs for apps that support OpenDocument.

I'm drifting so far off-topic that I'll stop now. :-)

Best regards,

Marbux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20061015/5eca27de/attachment-0002.html