|
|
| MA Asks: Can Anybody Out There Make MS Office Interoperate with ODF? |
 |
|
Wednesday, May 03 2006 @ 07:31 PM EDT
|
The Commonwealth of Massachusetts has posted a Request for Information regarding Open Document Format plug-ins for Microsoft Office. Here's what they are looking for, information on any existing or in-development plug-ins or converters that can allow Microsoft Office to open, display and save to ODF and also allow translation of documents between Microsoft's binary (.doc, .xls, .ppt) or XML formats and ODF. Thus, Microsoft is being publicly shamed, and maybe now they'll decide to bother to write such a plug-in. The thing is, Microsoft is the only one who knows all the details of their super secret interoperability information, unless somebody's been doing it the slow, hard way Andrew Tridgell told the EU Commission about last week at the hearings. If you have, the Commonwealth would like to hear from you.
Unfortunately for Microsoft, they just told the EU Commission they have trouble documenting their code. They might need to hire some more retired old geezers who still remember what's in their code. Or maybe contact some dudes with some l33t skills. Or they could admit they should just do this, or at least reveal the necessary information the community needs to figure out how to interoperate freely, and then the community will gladly write it in two shakes of a lamb's tail. The bottleneck is Microsoft. Here's the Commonwealth's request: Description: The Commonwealth seeks information pertaining to the existence or development of a "plug-in component" or other converter options to be used with Microsoft Office that would allow Microsoft Office to easily open, render, and save to ODF files, and also allow translation of documents between Microsoft's binary (.doc, .xls, .ppt) or XML formats and ODF. Respondents responding to this proposal need not be on state contract. The RFI is posted on the Commonwealth’s procurement website at www.comm-pass.com. In the middle of the page, click on “Search for solicitations”, enter “ODF” in Keyword box, and view the open solicitation (RFI 06-1). Click on the “Intent” tab to access the RFI document. By the way, ECMA now has the first draft of Microsoft's Office Open XML specification, all 1900 pages, listed as Creation of the Ecma XML document format standard, first draft as a zip file, along with a
PowerPoint presentation, as PDF. I notice on page 7 of the PowerPoint, titled "XML Strategy, Built - by design - for interoperability," it says the strategy is to "remove barriers to enable data interoperability, e.g. across Documents & Servers," with a little picture of a penguin sitting next to the Unix logo, so they do seem to be representing that they would like to interoperate documents with Linux. No? You cynics think they are just a prize bunch of hypocrites? Well, let's watch what happens next. If they mean it, they will write the plug-in or provide the necessary information so it can be done by others. If they don't, then I think it's plainly evident to the world, including Massachusetts, that interoperatibility is not their goal. On page 15 there is a tip of the hat to the EU Commission, and on page 16, they list their Office Open XML co-sponsors, and I note 6 of the 10 are not currently members of Ecma. Apple is on the list so perhaps they could write the ODF plug-in? No? Then on page 17, they give reasons why the world should standardize on Office Open XML, and one bullet point says, "Microsoft providing royalty free access to MS IP necessary to implement Office Open XML." OK. Thanks. But how about doing the same for ODF, so we don't get the impression Microsoft is more interested in locking us in to their XML rather than in making true interoperability possible? UPDATE: Peter Korn, the accessibility guy at Sun, mentions on his blog what it all means for the disabled if we have a plug-in: The goal of this RFI is to explore the possibility of an MS-Office plug-in or other convert to allow folks to keep using MS-Office but nontheless read and write ODF. This would address the immediate problem of any gaps in functionality that Windows Assistive Technologies have when used with ODF applications like StarOffice, OpenOffice.org, and IBM Workplace as compared to MS-Office. And I am so pleased to read there that the Bay State Council of the Blind is on the OASIS ODF Accessibility subcommittee now: Since the ODF Accessibility presentation at CSUN last March, there have been a few notable developments worth sharing.
First, the OASIS ODF Accessibility subcommittee is nearing completion of their Open Document file format accessibility audit. The subcommittee membership includes Sun Microsystems and IBM, the Royal National Institute for the Blind and the Bay State Council of the Blind, Design Science and the OpenDocument Foundation, and several unaffiliated individuals with deep expertise in accessibility (and about one third of the subcommitte themselves have either physical or visual diabilities). They plan to finish the audit at a meeting hosted by the Royal National Institute for the Blind later in this month. The output will comprise a set of specific, recommended improvements to the ODF specification which we hope to see incorporated in a "1.1" version of the spec. later this year. Looks like this story is going to have a happy ending.
|
|
|
|
| Authored by: Trollsfire on Wednesday, May 03 2006 @ 07:34 PM EDT |
If you find any errors, post corrections here so that PJ may fix
them.
--Trollsfire [ Reply to This | # ]
|
| |
| Authored by: fredex on Wednesday, May 03 2006 @ 07:40 PM EDT |
| so we won't have to read 'em in the wrong places. [ Reply to This | # ]
|
| |
| Authored by: DebianUser on Wednesday, May 03 2006 @ 07:42 PM EDT |
How hard is it to turn OpenOffice.org into a Windows plugin? Firefox seems to
swallow the Acrobat reader "whole", so to speak, at least in the linux
version. [ Reply to This | # ]
|
| |
| Authored by: webster on Wednesday, May 03 2006 @ 07:46 PM EDT |
1. If someone comes up with a plug-in soon, wouldn't that be embarassing.
2. If such a plug-in is produced, the Office people will send out a patch that
fixes it so it won't work.
3. They will also say that it violates their patents and trade secrets. They
will say that it is an attack on their innovation.
4. Since China may be coming into the fold, they will say that Massachusetts is
the only remaining Communist State.
---
webster
[ Reply to This | # ]
|
| |
| Authored by: overshoot on Wednesday, May 03 2006 @ 08:02 PM EDT |
The Commonwealth seeks information pertaining to the existence or
development of a "plug-in component" or other converter options to be used with
Microsoft Office that would allow Microsoft Office to easily open, render, and
save to ODF files, and also allow translation of documents between
Microsoft's binary (.doc, .xls, .ppt) or XML formats and ODF. Respondents
responding to this proposal need not be on state contract.
That's
a funny wording. Presumably a plug-in that would open, render, and save would
trivially do conversions. Therefore, if the bold text isn't to be redundant
they're looking for an independent converter.
That we can provide
trivially, since OO.o is scriptable for batch tasks like conversion.
[ Reply to This | # ]
|
- Ambiguity - Authored by: pdp on Wednesday, May 03 2006 @ 08:28 PM EDT
- Ambiguity - Authored by: Anonymous on Thursday, May 04 2006 @ 03:02 AM EDT
| |
| Authored by: etmax on Wednesday, May 03 2006 @ 08:33 PM EDT |
I believe the Australian NSW government has contracted someone to do just that.
I read it some 6 months ago, so hopefully it has progressed.
---
Max - Melbourne Australia[ Reply to This | # ]
|
| |
| Authored by: etmax on Wednesday, May 03 2006 @ 08:34 PM EDT |
I believe the Australian NSW government has contracted someone to do just that.
I read it some 6 months ago, so hopefully it has progressed.
This link covers the story:
http://www.smh.com.au/news/breaking/opendoc-plugin-for-ms-office-users/2005/10/2
0/1129775888552.html
---
Max - Melbourne Australia[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 03 2006 @ 09:02 PM EDT |
If they don't, then I think it's plainly evident to the world,
including Massachusetts, that interoperatibility is not their
goal.
No, interoperability is probably their goal. It's
just that they'd prefer everyone to interoperate with them rather than the other
way around :) [ Reply to This | # ]
|
| |
| Authored by: Felix_the_Mac on Wednesday, May 03 2006 @ 09:08 PM EDT |
Remember back in October at the time of the MA hearings?
Groklaw posted this
article:
French
Co. Writing MS Plugin for ODF Support Found
concerning a French
company, Clever Age, who was developing a converter?
Here are 2 web
sites:
Clever-Age.org
Clever-Age.com
The second is in French.
Here is the
sourceforge homepage
OpenOffice
Filter
Unfortunately they haven't posted any new code since
October. :-(
[ Reply to This | # ]
|
| |
| Authored by: Kilz on Wednesday, May 03 2006 @ 09:21 PM EDT |
Just a question, but why should anyone but Microsoft do Microsoft a favor? It
seems with this plugin Microsoft would be still able to continue its evil ways
and there would be little change. Mass would just continue to use MS office. It
wouldn't be a battle of what program is better. It would be the battle of what
program are you used to, so why switch away from M$? As we all know politicians
don't care how much of our cash they spend. At least if they have to use Open
Office it will save all us tax payers money.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 03 2006 @ 09:23 PM EDT |
PJ wrote:
"Microsoft is being publicly shamed"
I don't agree with this at all. Plugins are a way for the Commonwealth to keep
their existing investment in MS products while adhering to the new ODF standard.
That way, there is no retooling/retraining cost.
MS doesn't lose in this - MA keeps using MS products, instead of adopting open
source software. I certainly don't view this as shame for MS, or a victory for
open source.
The "Request for Information regarding Open Document Format plug-ins"
is an admission by the Commonwealth that they will keep using MS Office. And if
there are no plugins available right now, the Commonwealth of MA has now openly
declared that there is a market for them.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 03 2006 @ 10:05 PM EDT |
I got it:
ln -s /usr/bin/soffice.bin microsoft_office
There, that oughta get your (wink, wink) microsoft_office to read and convert
all
the docs and odfs you can throw at it, and then some.[ Reply to This | # ]
|
| |
| Authored by: Felix_the_Mac on Wednesday, May 03 2006 @ 10:09 PM EDT |
since ODF is freely available there will be nothing to stop them.
By developing converters/plugins now the initiative is removed from MS. That's
got to be good, right?
Yes, it does mean that, for example, MA would not have to ditch Office in order
to use ODF (as long as they are satisfied with the quality of the plugin).
But MA's goal was to ensure long term accessibilty for their documents NOT to
ditch Office.
The existence of the plugins removes the lock-in effect of the proprietary
MS-XML format.
So what about MS & ECMA (and maybe ISO)?
Well, if MS-XML becomes any sort of recognised standard it will serve to reduce
the changes that MS can make to the format and also allow developers working on
converters/plugins to produce more faithful conversions.
It looks as though the mouse that is ECMA will allow MS to push through MS-XML
as a ECMA standard. But what about ISO?
I think the best case scenario would be one of the following:
1) ISO refuses to ratify MS-XML
2) ISO ratifies MS-XML but is very strict in respect of proprietary extensions.
Failing that maybe states/governments will recognize the difference between a
true open standard and an MS 'open standard'. Minnesota is setting a good
example.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 03 2006 @ 11:00 PM EDT |
When Microsoft was crushing WordPerfect, Office would read WordPerfect files.
They even had Help for WordPerfect users. They made it as easy as possible for
WordPerfect users to migrate. Of course now that they own the market, any
migration is bad for them and they want to make it hard to migrate. They will
try everything to keep interoperability from happening.
btw. Formatting large documents is such a pain in Word that some of my students
are trying to learn LaTeX. That has to be why many people still use
WordPerfect.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 03 2006 @ 11:06 PM EDT |
It's their own fault and citizens should be outraged. They had a chance to
reign in the Redmond crooks long ago. They had them dead-to-rights, and let
them walk away for a paltry sum and no protection for citizens. Now they're
begging for a fix. MA residents should be screaming "Foul!".
The past sins aren't the end of it - recent sins are piled on and nobody stood
up to protect Quinn, an honorable man with the best interest of the people in
his heart. Instead they hung him out to dry, the victim of lies and innuendo.
For MA to now beg for M$ to fix things, and hint they'll even pay them to do it
is incredibly filthy. They should do the right thing: bring new anti-trust
action against Redmond. Hey at least some politicos might get rich selling out
the people again, so money would flow out of Redmond not in.[ Reply to This | # ]
|
- Shame on MA - Authored by: Anonymous on Thursday, May 04 2006 @ 12:27 AM EDT
| |
| Authored by: Anonymous on Wednesday, May 03 2006 @ 11:24 PM EDT |
So Microsoft has the code and still can't tell what it does.
I believe IBM should cite some of this testimony from Microsoft against SCO
should SCO continue the "we don't need to cite code". Here Microsoft
the author of the code is saying they can't even tell what the code does, what
methods and concepts it uses to get things done, when they have all the source
code and the developers notes. This shows the complexity that can be involved in
code and that methods and concepts can be deeply hidden in code.
[ Reply to This | # ]
|
| |
| Authored by: jcjodoin on Thursday, May 04 2006 @ 01:20 AM EDT |
| There's a Perl module that I used at a previous employer
to generate XLS .bin
files. I believe it also had .XLS
read capabilities as well.
I've slept
since then and its late / early now so you'd
better check for
yourself.
Click for CPAN article
here.
jeffrey
Also, there are Perl Modules to read
structured storage
which is what the office doc formats are stored in. Helpful?
Maybe ...
[ Reply to This | # ]
|
| |
| Authored by: mlwmohawk on Thursday, May 04 2006 @ 10:37 AM EDT |
Depending on the nature of your file, documenting the file format may be
impossible. I have worked on a large number of projects, some as a contractor
for Microsoft, for over 20 years.
Sometimes, the document layout and format is not documented from the perspective
of the file, but of the code that saves and restores its state. In C and C++, it
is often the case that data structures are written to a file with object codes.
When the chunk of the file is being read, the particular object that created or
can read the object (based on the code number in the file) is created and passed
the data.
There is no external document about all the various possible objects because
they can be added on the fly and can manage their own data which may be stored
in any format imaginable.
Typically, there is, maybe -- if you are lucky, a high level document that shows
the basic file header and chunk header. Everything else grows organically.
The office document format has grown and changed over the years and it may be
that no one really knows, or really ever knew, how the file looks on disk and
only that the file can be walked or parsed by software.
Now, multiply the possible data embedded into the document format, the changes
over time, and the variation of features for each revision, and it may be
impossible to document it.
This is a very strong argument of ODF. A file format like this (MS Office) is a
very function and useful structure. Many many programs operate on native data in
this fashion because it is quick and efficient, but usually, data is saved to a
more ridid format for archival or exchange purposes.
For instance, most databases work like this, however, you virtually never
exchange the database file, but an extract of it.
[ Reply to This | # ]
|
| |
| Authored by: mlwmohawk on Thursday, May 04 2006 @ 02:42 PM EDT |
"It is a design flaw. Storage formats must always be completely
specified."
There is a difference between "specified" and "documented."
A great example is the PostgreSQL project, www.postgresql.org. They fully
document their copy format for exchanging data, but they do not document their
"on-disk" database format.
Every object on the disk is defined by some structure or algorithm for reading
it, but there is no "file centric" document that states how write code
to read a postgresql table file. The PostgreSQL code, itself, is the
specification.
If you want data out of the database file, you are forced to use the database
code.
This is how most software operates, you'ld be hard pressed to find programs that
don't and if you did, there would be a hundred or so others that didn't.
Again, this is not "bad" per se' It is a very efficient and useful way
of doing it, but it does not lend itself to third party decoders.
The difference is whether or not the file format is incidental or instrumental
to the product. If interoperability is important, then the file format is
important. If interoperability is not important, i.e. the file is a temporary,
operational, or backup file, or you are Microsoft, then the file is incidental
to the application.
[ Reply to This | # ]
|
|
|
|
|
