01.24.07
Posted in FUD, GNU/Linux, Intellectual Monopoly, Microsoft, Novell, OpenSUSE, Patent Covenant, Patents, Red Hat at 10:01 pm by Dr. Roy Schestowitz
This item brings together a collection of Novell-related news.
Let us begin with a new Red Hat hire. It is rather interesting that a former executive of SuSE has just decided to work for Novell’s fierce rival. Could he be following the same road as Jeremy Allison due to similar sentiments involving bitterness and disdain?
Red Hat Hires Ex-SUSE Sales Exec to Run EMEA Channels
Linux distributor Red Hat said last week that is has brought on Petra Heinrich to be its new director of channels an partners in its Europe, Middle East, and Africa region.
This article’s description of his background seems to suggest that everything remains possible. A departure that results from the divisive Microsoft/Novell deal, however, did not seem to repel the co-founder of SuSE.
Moving on, have a look at the worrisome choice of words in the following article:
Novell-Microsoft Deal Is Mixed Bag
“People who read into the Novell-Microsoft pact that Novell has any intention of doing anything other than figuring a way to sell more Novell Linux — and do it in a way that protects its customers [from patent disputes] — are seeing hobgoblins,” Amy Wohl, founding analyst for Wohl Associates, said.
Yet again, patents are being mentioned as though they have some validity.
On a brighter note, Novell contributes some nice new tools.
Novell Enhances Linux Development With New Open Source Services
Novell today announced the open source availability of the openSUSE Build Service, an innovative framework that provides an infrastructure for software developers to easily create and compile packages for multiple Linux distributions.
Permalink
Send this to a friend
Posted in ECMA, Europe, Formats, Office Suites, Open XML, OpenDocument, OpenOffice, Standard at 3:00 pm by Dr. Roy Schestowitz
As you must have heard by now, Microsoft has resorted to gutter-level tactics in its race to have a monopoly enabler approved as a standard. It gets worse.
Open source lobby fury over Office format fast-track
Open source lobby fury over Office format fast-track
The duo claim the process means Europe is being ‘railroaded’ into accepting an ‘inadequate’ standard.
This gives even less time for criticism to be expressed and rebuttals revisited, through documents such as that which Groklaw has just produced:
Others have expressed that the ISO standardization of Ecma 376 in its present state would result in an international standard that no vendor other than Microsoft could fully implement. And still others expressed doubts whether a Microsoft-sponsored plugin for its office suite will be able to provide sufficient fidelity in conversions/transformations between Ecma 376 and ISO/IEC 26300.
Some of these recent developments have “corruption” written all over them. It should not be surprising though. With the future Office lockins, there are tens or hundreds of billions of dollars in stake.
Permalink
Send this to a friend
Posted in Antitrust, Formats, Interoperability, Microsoft, Novell, Office Suites, Open XML, OpenDocument, OpenOffice at 2:31 am by Shane Coyle
Here are two articles on the da Vinci plugin for Microsoft Word, which is promising full fidelity transformations from Microsoft legacy binary formats to ODF from within Office itself.
The articles are extensive, covering the history of the ODF/OOXML arguments, including Massachusett’s open file format policy, as well as technical and procedural/workflow aspects and ramifications of the converters.
This article discusses full fidelity transformations, and some of the impact that lossy conversions could have on preventing ODF adoption, as well as how da Vinci handles "dark objects" in MS file formats (the "elusive 15% just beyond the reach of the OpenOffice.org conversion engine.").
Most people believe that full fidelity file conversion is impossible, largely influenced by the poor fidelity generally experienced in converting documents from one vendor’s binary file formats to another vendor’s binary file formats. The major reason some people transfer such beliefs to the daVinci plugin is that they do not realize the plugin works natively inside Microsoft Word. The Word program itself performs the conversions using its internal processes for native support of a file format. The da Vinci plugin triggers the native Microsoft Word conversion process, intercepts the output at precisely the right moment, and maps it to ODF. When opening an ODF document, da Vinci simply reverses the process (although there is nothing simple about what da Vinci does or how da Vinci does this).
Think of it this way. The Microsoft Compatibility Pack is a EOOXML plugin for older versions of Microsoft Office. If these versions of Microsoft Office can use a plugin to perfect a conversion process between legacy binary formats and EOOXML, the same process can be used for ODF. In fact, it’s actually easier to perfect a similar conversion process to and from ODF instead of EOOXML, particularly for Microsoft. Easier in that the ODF specification is lean and clean by comparison and very carefully structured. Even easier if you have the blueprints for those binary file formats.
Here are some technical details on how the da Vinci plugin works, including a simplistic overview that is really a simple and elegant solution that leverages Microsoft’s own XML conversion. The article also outlines some of the other Office to ODF converter projects and the manner in which they address the problem, usually leveraging OpenOffice.org’s conversion engine.
When a user loads a binary document (or creates a binary document in Microsoft Office applications), the apps themselves convert the binary documents to IMBR (the Microsoft Office apps in-memory-binary representation).
The user works the document in IMBR mode. This means all application features, business process adaptations, assistive technology add-ons, whatever, are available and cooking without disruption or change.
When an internal MS conversion process of IMBR is triggered, daVinci intercepts the results, and maps to ODF. The ODF version is saved to file.
An internal conversion process is triggered whenever functions like save, save as, open, or open most recent is called for.
Perhaps the most interesting aspect of the da Vinci plugin is that it provides the ability for users to select ODF as the default file format within Office, providing the native support for ODF that Stafford Masie was expecting, and neither Novell nor Microsoft delivered on the promise, but rather it was the OpenDocument foundation.
Permalink
Send this to a friend
Content is available under CC-BY-SA