OpenOffice - OpenXML Translator

A partir de agora os usuários do OpenOffice.org não precisam se preocupar em receber um documento com extensão .docx

The goal for this project is to provide translators to allow for interoperability between applications based on ODF (OpenDocument) 1.0 standards and Microsoft OpenXML based Office applications.

http://odf-converter.sourceforge.net/

http://download.novell.com/SummaryFree.jsp?buildid=ESrjfdE4U58~

Novell lança plugin OpenXML para OpenOffice.org

* Ver
* Rastrear

Posted março 8th, 2007 by filhocf
in

* Desenvolvimento
* Novell

A partir de agora os usuários do OpenOffice.org não precisam se preocupar em receber um documento com extensão .docx: um plug-in apresentado pela Novell reforça a interoperabilidade, embora demonstre que, como sempre, são as empresas de Linux que se beneficiarão com o processo.

Correspondentes do ITwire indicam que embora essa ferramenta exista, o Linux ainda não tem a aceitação que necessita para impôr-se no escritório, onde elas realmente fazem sentido.

Além disso, informam que o “tradutor” de formatos ODF e Office OpenXML também pode ser utilizado na versão Windows do OpenOffice.org, que ganha mais alguns adeptos com esse tipo de recurso.

Página para baixar o ODF Converter:
http://download.novell.com/SummaryFree.jsp?buildid=ESrjfdE4U58~

Not to be confused with OpenOffice.org (an unrelated office suite) or "Open Office XML" (a colloquial synonym for OpenOffice.org XML).

Office Open XML (commonly referred to as OOXML or OpenXML) is an XML-based file format specification for electronic documents such as spreadsheets, charts, presentations and word processing documents.

Microsoft originally developed the specification as a successor to its binary Microsoft Office file formats and it was handed over to Ecma International to be developed as the Ecma 376 standard, which was published in December 2006.[1]

Controversially, the specification is currently undergoing fast-track standardization within the International Organization for Standardization (ISO) as DIS 29500 (Draft International Standard 29500), but the draft text has failed (as of the September 2007 ballot) to reach sufficient approval from ISO national body members to be accepted as a standard. A ballot resolution process will allow for the text to be amended and a final decision to be reached on its acceptability for standardization.

“Uma das minhas atribuições profissionais é representar oficialmente a IBM em entidades de padrões como a ABNT. Como estamos no processo final de avaliação da proposta OpenXML e a poucos dias de definir o voto brasileiro na ISO, tenho dedicado grande parte do meu tempo a esta atividade. Isto se reflete nos inúmeros posts que venho levantando sobre o assunto.

E, aqui vai mais um... Recentemente estive debatendo com professores e estudantes de diversas universidades sobre esta questão. Vou resumir alguns pontos debatidos.

Tenho começado o debate mostrando que já existe um padrão para formato de documentos, independente de fornecedor e aprovado pelo ISO desde maio do ano passado, que é o ODF. Agora, estamos debatendo a proposta da Microsoft e da Ecma de criar um segundo padrão. Esta proposta chegou à ISO através do processo chamado fast track, com um exíguo período de seis meses para as entidades de padrões (o Brasil é um deles) avaliar as suas mais de 6.000 páginas de documentação.

Uma pergunta que me fizeram várias vezes: “Porque dois padrões?”.Uma das principais alegações para apresentar este segundo padrão é que o OpenXML foi desenhado para garantir compatibilidade com os documentos legados do Office (vejam bem, apenas do Office...). Na proposta Ecma isto é claro: “OpenXML was designed from the start to be capable of faithfully representing the pré-existing corpus of Word-processing documents, presentations and spreadsheets that are encoded in binary formats defined by Microsoft Corporation”. Bem, então para garantir esta compatibilidade é necessário um segundo padrão? Por que não ampliar o padrão já existente, o ODF?

A resposta pode ser encontrada na própria especificação do OpenXML, onde em vários lugares lemos coisas como “2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing). This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95)…”.Ou seja, apesar das 6.000 páginas temos que saber exatamente como o Word 95 funciona! Então, não apenas temos que digerir a imensa documentação, mas temos que saber emular o Word 95, Word 97, Word 6, etc...! E quem sabe fazer isso, a não ser a Microsoft? Aí entra uma pergunta “Um padrão aberto pode requerer extensões proprietárias para poder ser implementado?”. A resposta deve ser um sonoro não!

Portanto, o caminho mais sensato seria ter um único padrão. Dois ou mais padrões aumentam os custos para todos. Com dois padrões não temos o dobro de benefícios que teríamos com apenas um...Ah, indaga alguém: “mas já existem padrões que overlapam uns aos outros...”. Bem, o fato de isto acontecer não significa que temos que perpetuar o erro. Padrões não devem ser duplicados. Se já existir um padrão aberto, porque não agregar esforços e evolui-lo? Criar um padrão alternativo para competir com o já existente só beneficia a quem o propõe.

Mas, vamos em frente, analisando as diversas documentações livremente disponíveis na Web (o blog lista inúmeros, que podem ser acessados pesquisando-se pelas tags ODF e OpenXML), coletei algumas deficiências do OpenXML, que cito nos debates, como inconsistências com padrões ISO já existentes (OpenXML implementa “language codes” diferentes do padrão ISO 639. E conta-se às dezenas tais casos...) e uso de padrões proprietários, como Windows Metafiles e Enhanced Metafiles.

Outro ponto que faço questão de lembrar é que a única implementação do OpenXML é a da Microsoft. E mesmo assim, de forma parcial. Na verdade o padrão OpenXML foi criado em torno da aplicação Office. Uma inversão de propósito. Além disso, lembro que existem restrições de interoperabilidade entre sistemas, uma vez que o OpenXML define funcionalidades existentes apenas no Windows, como DevMode, GUID e ClipBoard Data. Estas dependências fazem com que o OpenXML não funcione da forma correta em ambientes que não o Windows.

Bem, padrões são por natureza complexos e altamente técnicos. Um processo fast track limita em muito a sua análise de forma criteriosa. Aliás, como recordar é viver, vamos lembrar a tentativa anterior da Microsoft e da Ecma de propor à ISO, via fast track a aprovação das extensões C++/CLI. Como vocês podem ver em http://www.robweir.com/blog/2007/03/fast-track-wrong-direction.html, a proposta foi abortada pela avaliação negativa das entidades de padrões. Lessons learned? Se a proposta não for bem feita, as entidades de padrões podem e devem rejeitá-la, mesmo diante das carências de tempo sob fast track.”

Add Favorites / Bookmark

importar no delicious