Brian Jones - New Office file formats announced
- Posted: Jun 01, 2005 at 8:59 PM
- 242,964 Views
- 119 Comments
Jean Paoli was bouncing around the offices here in building 18 today. Who's he? One of the co-creators of XML. Why was he happy?
Because Office just announced their new file formats all built in XML.
"We just turned on 400 million new people to XML," he told us.
Other reports?
Mary Jo Foley and a bunch of other reports. More will be appearing on Microsoft's Office XML page.
This is big news for developers.
Here Brian Jones, program manager on the Microsoft Word team, talks all about what it means.
This is a HUGE change for the Office team. For the first time the default file format will be open and accessible by anyone.
Brian gives us a demo of how you will be able to look inside the new file format at 19:30.
So, what was announced?
Word, Excel, and Powerpoint will get a new file format all based on XML.
The extensions will change from .DOC, .XLS, .PPT to .DOCX, .XLSX, .PPTX.
The new file format is actually enclosed in a ZIP file. Change the extension name to .ZIP and you'll be able to double-click and get access to all the pieces of the new format (Brian in his demo shows what it looks like).
The new file format will be usable on existing versions of Office.
And, as extra icing on the cake, Brian Jones is now blogging as well.
Because Office just announced their new file formats all built in XML.
"We just turned on 400 million new people to XML," he told us.
Other reports?
Mary Jo Foley and a bunch of other reports. More will be appearing on Microsoft's Office XML page.
This is big news for developers.
Here Brian Jones, program manager on the Microsoft Word team, talks all about what it means.
This is a HUGE change for the Office team. For the first time the default file format will be open and accessible by anyone.
Brian gives us a demo of how you will be able to look inside the new file format at 19:30.
So, what was announced?
Word, Excel, and Powerpoint will get a new file format all based on XML.
The extensions will change from .DOC, .XLS, .PPT to .DOCX, .XLSX, .PPTX.
The new file format is actually enclosed in a ZIP file. Change the extension name to .ZIP and you'll be able to double-click and get access to all the pieces of the new format (Brian in his demo shows what it looks like).
The new file format will be usable on existing versions of Office.
And, as extra icing on the cake, Brian Jones is now blogging as well.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
More posts in this blog
-
Jesse Kaplan -- Will your .NET 1.1 apps work on…
-
Brian Jones - New Office file formats announced
-
Imagine Cup competition
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
'nuff said
Really Cool! I just got home and it was right when this got posted. I can't wait to see the Reference Schemas. You said it would be on the Microsoft XML page...when will it be up? Can you post a link to Brian's blog so we can all subscribe?
The other pages will be up soon.
Backward compatible: There will be updates to Office 2000, XP, and 2003 that will allow those versions to read and write this new format. You don’t have to use the new version of Office to take advantage of these formats. (I think this is really cool. I was a big proponent of doing this work)
nice
1) There's simpler file formats.
2) Even though the current suite can write the new file formats, the suite is still buggy & has high maitenance cost.
3) Some maverick within MS proposes writing a new Office suite to deal directly w/ the simpler file formats
4) The newly proposed Office suite is inherently simpler & therefore, more robust and has lower cost, the maverick says.
5) The maverick got the OK -- as long as he writes the new Office suite in .NET -- lower dev cost & all.
6) Right around Longhorn release, the maverick finishes Office.net and there is finally a reason to upgrade to Longhorn.
OK, here's why I want a new Office. When I open Word, there are 1,000 UI elements staring me in the face when all I want to do was to type a note. Since Longhorn is all about visualization, how about some adaptive UI for the new Office? I'll thank you personally.
As a document system and interoperability guy, I must admit this is very exciting. I am particularly taken with the lessons learned from the last format change (to docfiles in Word 97) and the careful use of Zip as a packaging technology for hierarchical inclusion of content, components, and anything else you want to carry around (including the old format in the test version that Brian demonstrated).
The retrofit of the new format all the way back to Offices 2000, XP, and 2003 is also heartwarming as a powerful move to sustain interoperable reach across generations of the application.
The document-management, content-management folk are not going to miss the value of this, and the comment about Sharepoint appeal is going to catch a lot of attention from those with ideas about other interoperable applications of distributed documents.
This is goodness guys.
(I notice I comment like I am blogging, so now I'll go do that too.)
Hip, hip, hooray!
Hurrah!! Really, this is awesome news. Hopefully, people will take full advantage of this! At any rate, this is very very cool!
yes, i still remember the Office 97 is able to open the new file formats of Office 2003(it's shocking), you know, our company is only able to makes a 2003 version app to open up a file formats of 97 verion.
Office 12 will still be able to open up Office 97 files and will still be able to save as the binary format that Office 97 will be able to open up.
By the way, why haven't you upgraded? Office 2003 is a LOT better than Office 97.
this is means that we as programmers need a convert tools for compatible with Office 97 and Office 12.
i knew it, i used to a legal Office97 in company, and use a piratic Office2003 at home.
No, you just need to stick with the old binary file format if you need Office 97 compatibility. No converter needed.
But does it makes the given reasoning for MS not participating in the ODF design process seem all the more shallow.
why not use .xml(or .msoffice) as unified file extension of Office(includes Word ,Excel,PowerPoint,etc).
then we are able to open and edit the .xml in the unified IDE(office , just like Visual Studio IDE ).
That would defeat the point of filename extensions under Windows. VS is an IDE, yet there's absolutely no need for all the files it handles to have the same filename extension. It would be a nightmare for your average users to understand.
just like the .sln(xml) file, users don't care about what is it(VC,VC#, Word, Excel), just need to double click for open up it.
you also can use different Icons to distinguish the different .sln files .the Icon has the word signalment when use Word to export a .xml file,the Icon of file should be the Excel signalment when use Excel to export a .xml file, .
could you guys to provide a plug(or office sevice pack) for the older Office(97,2000,XP,2003) to directly open the new file format up?
What happens when you save the document as docx? Does the excel object become a binary ole file inside the zip container, or does the object become an Excel xml referenced from the word xml file?
How does Word know which embedded objects can be persisted as xml files rather than binary ole objects?
Too long for an extension and too confusing for customers. Adding an 'X" is probably the best thing to do at this time.
Scoble already said, Office 2000, Office XP, Office 2003. Thats it. No Office 97.
one default extentions for all files ??? ,,,, mmmm
is a great idea, all the documents are "objects" and they are independent serialized objects in Xml format ... I like this a lot
Bye from Spain
El Bruno
http://spaces.msn.com/members/brunocapuano/
Edit:
Why are the whitepapers in Word format? Surely they should be in PDF format?
Q. Are the formats going to be licence encumbered like the current (old) XML formats? I mean we have been able to look at XML from office for a while now, but to use the format you had to agree to all sorts of stuff that wasn't terribly attractive for the ISV.
Tom
Hey Scoble,
why the link to Mary Jo Clueless?
for example:
http://www.microsoft-watch.com/article2/0,1995,1820607,00.asp
she says that
"Developers say there's a dirty little secret about Longhorn that few Softies are discussing publicly: Longhorn won't be based on the .Net Framework."
and later in the same trash:
"(Maybe Microsoft's revelation on Wednesday that the .Net Framework 2.0 beta is breaking applications has something to do with this? We're waiting for official word back from Microsoft.)"
this is just one of many times where her facts and information are false, wrong, misquotes or in some way missing key information.
I posted a reply to her "talkback" and I see it's gone. I guess she did not care for my telling her she was wrong and that I could make up junk like that easy and that perhaps I should work there ....
I don't have a problem with storys that ask questions or reveal facts .... but when it's a mess of bad quotes, half truths and guesswork it get's me Angry!
I don't know - and really, no client that I know of has used open office, so I don't really care.
Would be nice to think this new openness will extend to whatever cool UI they put on Office 12. Be nice to be able to give our apps the same look and feel and save us all from reinventing the wheel.
Also, even though I'd imagine Office 12 is a little way off yet would MS consider releasing the updates for Office 2000, XP and 2003 earlier so that we can start building apps for it before Office 12 is released?
It is an evolution (therefore mostly the same). Clearly, it will be updated to incorporate new "Office 12" functionality. Another type of change is structural - some of the features, such as document properties, that are common across all the applications or are a type of content that is likely to be manipulated on its own have been broken out into their own separate "part." This'll make it easier to manipulate this type of information in a programmatic way in solutions. The other change is that things like images and OLE objects are stored in their native binary form rather than as encoded XML, since we've heard from customers that this is the preferred way to work with these types of things.
I actually don't know what's going on regarding namespaces - we'll have to hear from Brian on this. Regardless, "Office 12" will be able to read and write the Office 2003 XML as well, so solutions built today will continue to run.
Wait! Stop the presses...
Is this spec tangled with expensive patents?
"Microsoft may have patents and/or patent applications that are necessary for you to license in order to make, sell, or distribute software programs that read or write files that comply with the Microsoft specifications for the Office Schemas."
That one question will determine if there is cause for celebration.
Yeah, he's got a point, what about PST XML files?
But you have to keep reading.
Finally a format that I can leverage directly without COM control of an installed OFFICE application. Our Grid control will finally be able to write to an Excel file directly. Our letter managers will be able to do the document creation from Word teemplates without having to COM interop on word thus avoiding all the mess that is Com interop with version differences and different default conditions in one installation over another and what not...
Kudos Microsoft for finally listening...
Let the countdown begin....
T minus 1.5 years and counting.... sigh....
Um... please, no... XML is many things, but space-efficient it is not.
How about ditching .pst files and using a SQL backend for local Outlook storage instead?
Let me make sure I'm interpreting this correctly.
If I want to write a utility that converts (say) PowerPoint .pptx files into a series of static HTML pages... then do I have to license the patent or not?
What if I want to sell the utility?
That page is the license; by reading it you have the license. So yes, you can freely write (and sell) that utility without asking Microsoft or signing anything anywhere. You can even do that today with the Word and Excel 2003 XML formats.
What about Access and Publisher? No .mdbx or .pubx?
Access and Outlook's PST are database formats (i.e. the whole point is that you can add and remove data from them and search them quickly) so it wouldn't make any sense to turn them into XML-zips.
As for outlook using SQL Server locally, that would be cool from a geek point of view, but the fact that it doesn't exposes a real flaw with Microsoft's SQL Server embedded strategy. Although SSExpress is pretty lightweight, it's still an out-of-process server and another dependency that has to be installed for a given app to work. If MS made a version of SQL Server that was literally just a DLL you could link with your app, then applications like Outlook could use it. They should take a look at VistaDB.
Good QUestion!
in fact in a "Standard" zip file the end of the file is where the "Directory" is stored so if you have half a file then you have no list of files to expand... there are tools that can scan a zip and determine some of the data though... it's been a while since I had to fix a bad zip.
(http://www.tallent.us/blog/CommentView.aspx?guid=5990589a-fe83-48af-bbcd-fbe6cbe74b06)
, and I *still* can't add ExcelML to my apps because of clients and even employees not yet using Office 2003. Giving outdated Office users a path for backwards compatibility will remove developer worries about moving forward with these formats.
A few questions:
1. Can we still load *uncompressed* XML files if there is no need for an archive? When they saves, will they retain their uncompressed state if nothing is embedded that requires enclosure?
2. Why Zip files? Obviously decent compression, but why not one of the XML-based schemas for XML and binary enclosures, (e.g., Echo/RSS)?I just RTA, found the answer...
3. Will Office VBA developers have direct access to the XML DOM? That would be *sweet*.
4. Will the Excel ODBC driver be updated to work with these XLSX files natively? If so, will the 255-character ROWSCAN truncation issue be resolved?
5. Will an entire Excel workbook be considered a single XML file as before, or will worksheets be stored as separate XML files? (my vote is for the same single-file format, FWIW).Nevermind, found the answer in the article...6. For PowerPoint, I would love to see the opposite: separate files for each slide, allowing easy programmatic means of compiling presentations from libraries of "best practice" slides. PPT is actually the most exciting prospect of the three to be able to access via ZIP code.
7. For Word forms, where will current form data be stored? In a separate file like Acrobat's XFDF?
8. For secure files, which ZIP encryption standard will you be employing, if any? The WinZip method or the PKZip method? I seem to remember that there was some patent frap about this a few years ago...
9. While you are at it, any built-in support for SVG in any of the applications?
You guys been learning from people who choose not to patent?
This is PATENTLY UNTRUE. Read the page again.
You need to include the following language in your products (prominantly displayed in both the license and documentation):
"This product may incorporate intellectual property owned by Microsoft Corporation. The terms and conditions upon which Microsoft is licensing such intellectual property may be found at http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp."
Simply reading the notices is NOT sufficient.For Microsoft to get me to put my information in "office" format, two free tools are needed.
a) A stand alone diff tool, that can be driven from the command line as well as the GUI. This would let me put office documents in a source code control and still track changes people make.
b) A asp.net tools that “renders” the document in such as way as ALL web users can read it.
i) If the use has office 2006 installed, send it back as is
ii) If they have an older version of office without the new converter installed, then convert to “doc” format on the web server and sent it back.
??) If they have open office, send it back in that format!
iii) If they can cope with PDF, sent it as a PDF
iv) otherwise convert to HTML
This would allow me to use office format on a companies document management system, and know that ALL users could read the documents.
Ian Ringrose
www.ringrose.name <- email on web site
Absolutely - I stand corrected. Sorry for the confusion! I am not a lawyer and should not be trying to interpret legalese.
But can't that be said of any application that is written in .NET and runs on Windows anything?
Not sure what your point is. For those wanting more clarity around the licensing, the following page is very good: http://www.microsoft.com/Office/xml/faq.mspx
Hey, I was just feeling trollish this morning
Btw, the /. crowd is complaining that this license is too restrictive (since it apparently includes language that allows Microsoft to revoke the license if you sue Microsoft).
So, if you have an Excel file embedded in a Word document, you could crack open that Word document and you would find a .xslx file. You could then crack that Excel file open too if you wanted and see what it has embedded.
Metro is closer to that All in One file format. as it is a PDL and Persistance format (metro reach) and a printer Spool all in one.
The Document API takes into account a Container (metro uses zip also) and document manipulations. although it does to appear to lose some of the fidality, (print to metro from PPT appears to lose the round trip without massive xslt work)
Since Metro will work with the new font engine in Avalon, any chance that O12 will have access to use the new open type features that Avalon documents will support??
Douglas
Frankly I don't think that (and I really hope they didn't) make this change to placate the open source crowd with a sort of "me too" type of thing.
I hope that this is a considered move on microsoft's part to make it eaiser for ISV's such as myself to interact with office documents so that I and other microsoft customers/partners can make more money selling "Proprietary" office solutions.
This is what Open Office does.
My reaction is more: "Finally, you goddam M#()$ F_#@ers..."
I've always wondered how we delude ourselves that we live in the Information Age when that information is locked up by some rich c&$*s in America. F#$& you.
Go ahead and censor this.
However, there were no answers about Microsoft providing XSL transforms into DocBook or XHTML---third parties have to write their own (and the Office schemas "keep changing").
Although it would be nice to support the format that was designed for Technical documents natively in Office. It would be nice to see the Book format in Office completely overhauled so that it works
Especially with distributed writing resposibilities.
perhaps a .bookx format With a top level container that contains the outline of the book. and references the actual Docx files that relate to the chapters.
Although I havent tried the compound document platform in 2k3, I know in 97, 2k, and XP it was almost unbearable to work with at times. especailly when multiple writers were involved.
douglas
Isn't that similiar to IE? Just MSHTML DLL that apps link to?
If it is, I'm getting spooky sense of deja vu.
Got to love the Slashdotters.
Also, you make me sick.
Exactly! Though I'll not bring myself to express in this manner.
Then why are there more GPL projects than BSD? Source: http://sourceforge.net/softwaremap/trove_list.php?form_cat=14
Top 3 licenses:
GPL - 44129, LGPL - 7210, BSD - 4617
I find it a bit of a surprise that there are licenses that have no projects. I would expect at least one (from the license writer) - although the files could be hosted somewhere else.
BSD benefits those that want to take someones work and give nothing back in return (or they want to release freeware, as they have some code that may be valuable for them - i.e. used in future products, or licensed to other). Although for small, simple projects BSD may be worth it (i.e. something you have written in a couple of hours). The authors of a license will always say theres is superior, but different licenses are needed for different software.
BSD is good for commercial entities, but when you use the GPL, software can evolve more rapidly, as changes have to be made available.
Can you work around the GPL by writing a 'wrapper' library and using the LGPL? Perhaps if that is not enough do a wrapper of the wrapper with a BSD license.
I agree with this sentiment, once a document is loaded into Word, for example, I'd rather manipulte the XML, much more powerful than using the old API because frankly the API doesn't do stuff that I would like it too (for example inserting a subdocument between two other subdocuments).
Actually that page points to the Old Office 2003 XML FAQ. Anything about the new stuff has yet to be made fully public. If we assume that things stay more or less the same, then My original assertion remains. Most anything we chose to write in .NET may use Microsoft Patented Code. If the application is running on windows it may use Microsoft Patented Code. Thats is all....
It will make the document's content technology proof given that Office has such a wide customer base.
Long-term storage of documents/data is becoming a problem as they are tied to the version of an application. The change from O97 to O2000 is a case in point. Documents may have to be kept for 30 years or more.
A rule of thumb has always been to save the info in ASCII format. However, given that the new docs will be compressed it seems that bit 8 is still alive.
In this respect One assumes that the zip format in use is not propriety and will still be available in 30 years time.
Who cares, I hear you say!
Well, it could be information relating to your mortgage; the one that you pass down to your children.
Still shows out of all the open source licenses, GPL is far more popular.
The GPL is probably most popular with Universities and non-profits who cannot afford proprietary software.
When was that lawsuit?
BSD is probably better for those that want to make money on software, but for those that sell services and support, the GPL might be better. After all you still need people to write the code. Like what RedHat does with its distribution. Linux is more rapidly developed than FreeBSD, so developers do write more GPL code than BSD, just not developers for major software development companies.
RedHat may spend months on developing it and then it gets released and people create alternatives based on it for free. It appreciates that it may lost some customers due to this, but someone may come along and add features that are benefitial to everyone. That may end up with gaining them more customers as they would want support and far more prompt updates (with derivitives updates may be a day or two later).
The ones that may actually add the new features may be some that would not use there software otherwise.
No license can guarantee fast development. But if Linux was not released under the GPL (i.e. under a BSD license instead), it would not be where it is today. Didn't BSD get released before Linux? Yet there are only three major distributions I know of (FreeBSD, NetBSD and OpenBSD). I'm sure there are more, but nowhere near as many as those based on Linux.
Surely there are more Linux users than Apple MacOSX users? They have done a good job, but I suspect RedHat or SuSE have greater market share.
Yes you do need choice. BSD is good for some, GPL is good for others.
Anyone who wants to write an application either has to write it from scratch, use BSD code or use GPL code or another license. The difference with GPL software is that it can only really get better - as if you add improvements, other people have to have them as well. People shouldn't complain about the GPL - the only reason to do so is if there is similar software to what they do, only yours is not free. You do not have to use GPL code - it just means you may need to do more work.
What will customers choose? Often the free alternative. Unless you can offer better value through services and support.
MySQL and RedHat have proved that you can build a business on open source. The major powers on the internet use open source (not just GPL licensed, but BSD and others) - Google, Yahoo, Amazon. ASP.NET and Coldfusion seem to be the only platforms that compete with the open source alternatives (PHP, Perl).
Back on topic. I don't feel that any license that Microsoft comes out will appease GPL developers. Perhaps when the next version of the GPL is out it might be possible.
At the moment, the only real alternative to Microsoft Office (Open Office) is under the GPL license so I don't see it supporting this new format, unless the filters used are not governed by it. I could imagine users requiring Star Office to open these formats though as Sun is the main one behind OpenOffice.
The Office Open XML Formats use the same ZIP/XML conventions that Metro uses. So, you can use System.IO.Packaging in the WinFX SDK to open and manipulate the format. In fact, we'll be showing this at our TechEd session next week.
Now, the content is clearly different as Metro is a fixed file format whereas the Office Open XML Formats are for the rich document information needed for manipulating Office documents in a collaborative environment which includes, display, metadata, change revisions, comments, etc...
We will clearly provide tools and help to developers who want to work with files in these formats. It's just a bit too early to be able to give specifics. With the Office 2003 schemas we have already shipped a transform to HTML for Word in the Word Viewer. Simply install it, and you can find the XSL in the Office directory in the program files tree.
DocBook is an interesting thing, being a combination of data elements and display XML. A straight transform wouldn't be possible unless you gave the user a way to define the data-aspects of it as well.
What's the story with VBA and VSTO customisations?
For development, will we be able to store the xml and VBA inside it in plain text, so we can easily use source-code control, merging changes etc?
For production, will we be able to protect the file, such that the VBA code can't be viewed?
Will we be able to store VSTO assemblies in the file, so they can be distributed much more easily than at present?
Will I be able to digitally sign parts of the xml file, use DRM on bits of it etc?
The new stuff will abide by the same terms as the old stuff. We worked closely with a number of customers and governments to ensure the terms met their bars for openness; we don't see a reason to change them.
What do you mean by 'preview code?' We will release patches that allow versions back to and including Office 2000 to read and write files in the new format.
Hey Stephen, I answered a few of these questions back on my blog.
You have access to each part since it's just ZIP, so if you wanted you could sign and/or encrypt each part. We aren't going to have any built in functionality though for that level of granularity from directly within Office though. It would need to be part of a seperate solution.
-Brian
People telling so called it preview and referred an URL to Microsoft containing "preview". That's why I said preview.
So, are you releasing these patches on Monday? Or is that just rumors someone spawned?
to open the new Office12 file formats up directly, no more .net framework and WinFX.
http://channel9.msdn.com/ShowPost.aspx?PostID=73924Presumably the interior of the document is encrypted.
Probably a misinterpretation. We have a 'preview Web site' we just put up: http://www.microsoft.com/office/preview/ It doesn't have much on it now, but it does give you a way to sign up to receive notices of future information. We wouldn't release any patches outside of a formal beta because it all needs to work together.
There are a number of types of protections that can be applied; we will do the appropriate thing for each case. When you really want to control what people can do with content, you would use something like Rights Management. When you do this, the document is encrypted - it needs to be that way in order to enforce the rights. Sorry, no easy XML access. If you're using something lightweight like range locking in Word 2003, where the purpose is to create a more robust template or solution in order to help protect honest end users from messing up, the password is encrypted but everything else is in XML. This could be opened up and abused through XML, but then that feature is not intended for high security. There's a range of options between these, depending on the intended use of the feature. (I can see that we should document all these types of cases somewhere ... thanks.)
So a CompoundFileContainer generates basically a ZIP file?
--edit: Nevermind, in the Beta1 RC it has been renamed to ZipPackage. Question answered.
Windows is getting inspired by Linux....weeee...lol
Interesting Question. The ideal case would be the later.
The Answer is do not using OLE but .Net and XML where possible. When you have the ability to see Office as a single Program and Word, Excel, etc. are only Plugins it should not be a real Rocket Science (but even a lot of work).
-- Ok, I truly have no idea how the next office will implement this.
But I think there is a lack of innovation because some of the Ideas from OLE arent realized until today.
In an ideal case u have only one program (Windows) and file-format (XML). Accordingly to the unix idea everything-is-a-file there should be an everything-is-a-XML-element mentology. And so u can begin make the whole filesystem as an (virtual) single XML-File. Instead of filetypes there could be used the XML-Namespace.
-- I think something like this is the idea behind WinFS.
If the "Main Program" Windows opens an File (XML-Section with an special file-namespace in the Analogy) it should look in the registry with program is registered for the given Filetype (namespace). The Program is then started with is then responsible for loading and handling the file (section).
When the program (ie. Word) is up and the file (ie. .docx) contains a namespace the program can't handle by itself (ie. a .xlsx subsection) the program witch is registered is loaded and used for handling it.
-- Instead of inline-XML-data there could also be a XLink and/or XInclude
The presentation and handling of the section works mostly like OLE in the current aproach.
A more advanced approach would be to use a common rendering objects/environment - something like Avalon. Instead of returning a rectangular-bitmap-representation of the subsection, the handling program could return a Stream of Avalon-Objects.
In the example as given above Word could host the whole file and Excel handels the Excel-Subsection. The Data of the Excel Subsection is handeled by Excel and gets transformed to Avalon-Objects with are sended back to Word. Word itself transformes the Word-part of the file also into Avalon objects and then integrates the result from Excel. The Graphics Subsystem of Avalon is then presenting the Data to the user and gets input actions based on triggers (I think of a kind of dynamic created EventHandlers) embeded in the Avalon-Data.
Given so if the user now is editing the text of the word-part, the mouse and keyboard events are handeled by Word. But if the user clicks on an cell of the Excel-Table (given that the subsection described above is a table), the events are calling Excel-Methods.
Because this works transparent for user it may seem that word has the same possibilities than Excel - Excel appears as an kind of Ad-Hoc-Plugin for Word. Because the common interface is Avalon, the same works also in the other direction, when embedding an Word-Document into an Excel Sheet. Also the use of Avalon would give the possibility to draw the data in non-rectangular and auto-linebreaking bounds and possibly even over the content of the host-document.
-- a bit radical thinking so far, and I'm not a professional writer - but I hope you can understand what I mean. But please correct me.
Equation Editor was one of my favorite Word extras. IIRC it was actually developed by a third party (not Microsoft) who still sells a pro version? Is that true?
The "Equation Editor" is the small version of MathType witch is a typesetting-only version of Mathematica. But because it is just an OLE Plugin and not natively Word it has many Drawbacks:
- Fonts are looking horrible when resizing
- Terrible (meaning "no") vertical line-Align
Also the "Equation Editor" has a lack of Keyboard and Font Support. Even it is based on TEX. Personally I'm using MathCAD because of the better Keyboard Support and the more flexible Rendering (Graphs, better looking Fonts when resizing, etc.). But if u want to write technical Articles you are better at learning TEX and using Publicon (but you are better using TEX on Linux - then you can choose between more programs).The idea I've described above would allow to insert MathML directly into WordML and let the MathML-Program do the translation from MathML (to SVG) to Avalon witch would be rendered by Word. So if Word has mot MathML Support and you have a program like a Avalon based Version of Equation Editor witch can work as Plugin for Word (you need special interfaces witch aren't existing today) you wold have proper vertical align, and no resizing artefacts, and proper font-style choosing and rendering by applying the Word-Document-Style also to the Avalon-Code generated from the MathML-Code.
The only problem that keeps is the lack of Shortcut-Support of the "Equation Editor".
But currently tis is just an idea of mine - not a product of the near future like Office 12.
In Fact, this was the purpose to waste Word for my main use - even there are lot of good but expensive Programs witch do that work really good.
(I'm currently writing Scientific-Documents in HTML and/or TEX)
I just hope that Word will natively support MathML. There will still be room for applications like MathType (for better editing, etc.) but there are many problems with equations nowadays with both Equation Editor and MathType (mainly problems of spacing for inline equations and aligning of multiple equations).
There are more and more people in the scientific and academic fields who are writing thesis in Word because they are easier to edit and share on screen than a tex documents (both me and my roommates were required by our advisors to write the document in Word even though the main platform we worked on was UNIX).
There is still some times before Office 12 is released, so I hope this will make it into it.
Freney - We've heard this request from a number of different customers. I'll have more information over the next several months around the schemas and what our formats are going to look like. In addition, I'm trying to find out what types of things people would want to get out of our files, so we can look at providing good documentation and tools for transforming from our formats into other formats. MathML is definitely a common request.
-Brian
If you are able to go through Outlook's OM though, then there are things you could to do output Outlook data as XML. Here's an article showing taking Outlook tasks and outputting them as XML and then importing that into Word: http://msdn.microsoft.com/office/understanding/outlook/codesamples/default.aspx?pull=/library/en-us/dnofftalk/html/office06012004.asp
-Brian
-Brian
HI,
Wish to see the evolution soon !
Thanks
-Arun
You can get your first preview here. I posted example files in 3 formats:
-Brian
However, in this interview I haven't heard about some really important issues. Like protection, security, document autencity. What will happen if I set password to the Word document? It'll just use this password for ZIP compression? How do I know whether the document came from a reliable source and wasn't tempered? Ok, it is easy and exciting to replace a JPG image, but how would I know that it was replaced? It is easy to change the author's name in XML but not secure. I would really like Microsoft to make it possible to detect WHICH PART OF THE DOCUMENT was tampered (if it was). Security is a very important issue here, when Word and Excel go to open standards.
I hope in the next interview you will ask these questions!
Remove this comment
Remove this thread
close