Group items tagged

excerpt: The trend in Office development is the migration of solutions away from in-application scripted processing toward more data-centric development. Of course this is a primary purpose of Open XML, and it is great to see the amount of activity in this area. We've seen customers scripting Word in a server environment to batch process / print documents or for other automation tasks. In reality Word isn't built to do that on a large scale, it is better to work directly against the document rather than via the application whenever possible. The Open XML SDK unlocks a "whole nuther" environment for document processing, and gets you out of the business of scripting client apps on servers to do the work of a true server application (not to mention the licensing problems created by installing Office on a server). comment:  Gray makes a very important point here.  The dominance of the desktop based MSOffice Productivity Environment was largely based the embedded logic driving "in-process" documents that was application and platform (Win32 API) specific.  Tear open any of these workgroup-workflow oriented compound documents and you find application specific scripts, macros, OLE, data bindings, security settings and other application specific settings.  These internal components are certain to break whenever these highly interactive and "live" compound documents are converted to another format, or application use.  This is how MSOffice documents and the business processes they represent become "bound" to the MSOffice Productivity Environment. What Gray is pointing to here is that Microsoft is moving the legacy Productivity Environment to an MSWeb based center where OpenXML, Silverlight, CAML, XAML and a number of other .NET-WPF technologies become the workgroup drivers.  The key applications for the MS WebStack are Exchange/SharePoint/SQL Server.  To make this move, documents had to be separated from the legacy desktop Productivity Environment settings. Note th

I was surprised to learn that Florian's native document parser is a JSON like ripper of OpenXML visual objects.  He doesn't wrestle with structured objects, but simply treats everything as a visual object.  NOOXML might be closer to a virtual print driver than a OpenXML ripper.   So this has me rethinking the OCR/Scan methods used to rip paper documents to create Tagged PDF "structured object" versions.  Structured objects can easily be converted to interactive HTML-CSS or SVG.  Today Google released an OCR enhanced Android gDOCS app.  Not sure if it uses the Bricolage/Bento algorithm, but that would be an interesting approach. excerpt: the Bricolage algorithm for transferring design and content between Web pages. Bricolage employs a novel, structured-prediction technique that learns to create coherent mappings between pages by training on human-generated exemplars. The produced mappings are then used to automatically transfer the content from one page into the style and layout of another. We show that Bricolage can learn to accurately reproduce human page mappings, and that it provides a general, efficient, and automatic technique for retargeting content between a variety of real Web pages.

With Documents To Go for the Google Android platform you get read, write, create and sync support for Word and Excel 2007 (OpenXML formatted) documents, support for receiving and sending attachments through Gmail and other applications (including the free RoadSync Exchange beta client, open password protected files, and view Word documents with track changes so you can see what others have done to your document. ZDNet reviewer Mathew Miller also recommends that people check out the details of the DataViz Intact Technology to see how documents will be handled to maintain file formatting and structure throughout the process of editing. There are two YouTube Video demonstations of "Documents to Go" running on an Android. ........ No collaborative editing with MSOffice desktops, but this is outstanding stuff.

The king of clicks returns!  No doubt there was a time when the mere mention of ODF and the now legendary XML "document" format wars with Microsoft could drive click counts into the statisphere.  Sorry to say though, those times are long gone. It's still a good story though.  Even if the fate of mankind and the future of the Internet no longer hinges on the outcome.  There is that question that continues defy answer; "Did Microsoft win or lose?"  So the mere announcement of supported formats in MSOffice XX is guaranteed to rev the clicks somewhat. Veteran ODF clickmeister SVN does make an interesting observation though: "The ironic thing is that, while this was as hotly debated am issue in the mid-2000s as are mobile patents and cloud implementation is today, this news was barely noticed. That's a mistake. Updegrove points out, "document interoperability and vendor neutrality matter more now than ever before as paper archives disappear and literally all of human knowledge is entrusted to electronic storage." He concluded, "Only if documents can be easily exchanged and reliably accessed on an ongoing basis will competition in the present be preserved, and the availability of knowledge down through the ages be assured. Without robust, universally adopted document formats, both of those goals will be impossible to attain." Updegrove's right of course. Don't believe me? Go into your office's archives and try to bring up documents your wrote in the 90s in WordPerfect or papers your staff created in the 80s with WordStar. If you don't want to lose your institutional memory, open document standards support is more important than ever. "....................................... Sorry but Updegrove is wrong.  Woefully wrong. The Web is the future.  Sure interoperability matters, but only as far as the Web and the future of Cloud Computing is concerned.  Sadly neither ODF or Open XML are Web ready.  The language of the Web is famously HTML, now HTML5+

Here it comes - the "rich" Web experience based on integrated but proprietary 2010 technologies from Microsoft.  Note the comparative "advantages" listed in this article describing Microsoft SkyDrive, and comparing to Google Docs. excerpt:  Do you use Microsoft Office programs for creating documents and then use Google Docs to edit these documents online or as an offsite backup? Well, now that Office 2010 and Office Web Apps are available under public beta for free, here are some reasons why you should consider uploading documents, presentations and spreadsheets into Office Web Apps via Windows Live SkyDrive in addition to your Google Docs account. 1. Windows Live SkyDrive supports larger files 2. Document formatting is preserved 3. Native OpenXML file formats 4. Public Documents are in the Lifestream 5. Content is not 'lost in translation'  ....... When you upload a document in Office Web Apps, the application will automatically preserve all the data in that document even if a particular feature is not currently supported by the online applications. For instance, if your PowerPoint presentation contains a slide transition (e.g., Vortex) that is not supported in the online version of Office, the feature will be preserved in your presentation even if you upload it on to Office Web Apps via Windows Live SkyDrive. Later, when you download and open that presentation inside PowerPoint, it would be just like the original version. The content is not 'lost in translation' with Office Web Apps. Are you using Google Docs as a Document Backup Service?  Office Web Apps won't just preserve all the original features of your documents but you can also download entire directories of Office documents as a ZIP file with a simple click.

Excellent explanation and review from the Tim Anderson. I wonder how i missed this? Here is the summary statement: "..... You can also extend XAML with custom objects. The main requirement is that classes used in XAML must have a parameterless constructor. The procedure is straightforward. Define a class; make sure your application has a reference to the assembly containing the class; then add a namespace declaration for the assembly. You can then define elements in XAML that map to your class, and at runtime these will become object instances. XAML has a curious story when it comes to formatted text, especially in Silverlight. In one sense it is rather limited. XAML has no understanding of common formats such as HTML, CSS or RTF, let alone the fancy new OOXML. Silverlight developers have to interact with the browser DOM in order to display HTML." "... No escaping it: Silverlight .XAP bundle preserves the original XAML. That said, XAML with WPF actually is a document format. The full WPF has an element called FlowDocument and rich formatting capabilities. Silverlight lacks FlowDocument, but does have a TextBlock with basic formatting options via the inline object. It also supports the Glyph element. This is interesting because it is the core element in XPS, Microsoft's invented-here alternative to Adobe's PDF." ".... XPS uses a subset of XAML to describe fixed layouts. In consequence, and with some compromises, you can use Silverlight to display XPS." "..... The bottom line is that XAML is a way of programming .NET declaratively. Its more intricate features improve the mapping between XAML and .NET. The result is we have design tools like Microsoft's Expression Blend and a clean separation between UI objects and program code, which is a considerable achievement." ".... As ever there's a downside, and with Microsoft it's the classic: this is thoroughly proprietary, and the schema issues make it difficult to validate with standard XML tools." No

Recently the Rocketman and i have been arguing about webkit/Chromium DOM capabilities and limitations; like the failure to fully implement CSS3! Especially missing is support for CSS3 page layout / page break innovations. I realized that i didn't have a good understanding of browser DOM - client side issues, and came across this interesting post from Dave Ward concerning DOM and jQuery.
The core issue behind my discussions with the Rocketman have to do with creating a DOM view from OpenXML and ODF documents, and then passing that view to the webkit/Chromium engine. So we weren't all that interested in cross browser support or in how IE8 handles DOM-JavaScript. Dave Ward however not only provides a good discussion about DOM-JavaScript and the importance of jQuery as a force of interoperability, he also points out that Microsoft supports jQuery - including direct support within Visual Studio!
".....Though JavaScript itself is a great programming language, the document object model (DOM) can be a web developer's worst nightmare.  The DOM is a method through which browsers expose an interface allowing JavaScript code to manipulate elements, handle events, and perform other tasks related to a document within the browser.  While almost every browser implements an ECMA standard version of JavaScript, their DOM implementations are inconsistent and quirky at best.  In fact, if you've had bad experiences with client-side programming in the past, it's likely that the DOM was the true source of your frustrations, not JavaScript itself.  This is exactly the pain point which jQuery addresses....
..... "Officially supported by Microsoft - For many Microsoft developers, this official blessing is the clincher. Not only will Microsoft begin including jQuery with Visual Studio, but it is part of the default ASP.NET MVC project template. What's more, Microsoft Product Support Services has already begun offering support for jQuery."....

Florian's docx reader is now available for iOS high-touch devices.  Extreme fidelity for reading/viewing native docx documents.  I hope he is working on a Chrome eXtension version!!!!   The world urgently needs WEB ready - Web view-able docx business documents.   Conversion of docx to HTML sucks.   The ultimate Visual Document system would enable users to work entirely in the native document format of the authoring system.  Florian's reader can do this, but so far he's limited to iOS.  Seems to me that the exploding sync-share-store market sector (DropBox, Box, Egnyte, SugarSync, etc) really need native document viewers that are HTM5 browser ready. " Naverage Reader HD Features: ... Designed for business documents. View your business document in an unbelievable quality. .....Tracked Changes Support. View text insertions, text deletions and comments on your iPad. ..... Layout Fidelity. Headers and footers, footnotes, tables, paragraph numbering, frames, graphics layout optimized for business documents. .....Font Embedding. Corporate fonts on your iPad. .docx-compatible. Compatible with the new Microsoft® Word format (.docx)."