{"id":95,"date":"2008-10-05T23:40:26","date_gmt":"2008-10-06T02:40:26","guid":{"rendered":"https:\/\/devkico.itexto.com.br\/?p=95"},"modified":"2008-10-05T23:50:39","modified_gmt":"2008-10-06T02:50:39","slug":"por-que-o-opendocument-format-odf-e-importante-e-porque-fico-assustado-com-o-quao-negligenciado-o-mesmo-e","status":"publish","type":"post","link":"https:\/\/devkico.itexto.com.br\/?p=95","title":{"rendered":"Por que o OpenDocument Format (ODF) \u00e9 importante (e porque fico assustado com o qu\u00e3o negligenciado o mesmo \u00e9)?"},"content":{"rendered":"

\"\"<\/a>\u00c9 interessante se fazer a pergunta: por que x \u00e9 importante? Antes de iniciar o desenvolvimento do projeto ODFEasy, sabia que ODF seria algo “importante”, mas nunca havia sentido na pele<\/strong>\u00a0a sua necessidade. Afinal de contas, se j\u00e1 temos o Microsoft Office, por que precisamos de outro formato? A pergunta se responde: exatamente porque temos o Microsoft Office e, basicamente, APENAS o Microsoft Office.<\/p>\n

Como desenvolvedor, 95% das vezes, opto por trabalhar com ferramentas abertas, principalmente Java. E, neste processo, vez por outra faz-se necess\u00e1ria a gera\u00e7\u00e3o de arquivos no formato do Office (no meu caso, 99,9% das vezes, planilhas). \u00c9 a\u00ed sempre o mesmo problema retorna. Se voc\u00ea est\u00e1 desenvolvendo na plataforma .net, sempre h\u00e1 como integrar sua aplica\u00e7\u00e3o ao Office via automa\u00e7\u00e3o e, a partir dai, gerar o que voc\u00ea sonhar. Se n\u00e3o quiser trabalhar com automa\u00e7\u00e3o, h\u00e1 uma ou outra biblioteca que lhe auxilia na gera\u00e7\u00e3o desta tarefa. Normalmente, estas bibliotecas n\u00e3o abrangem 100% do formato, mas acabam por quebrar o galho.<\/p>\n

J\u00e1 se voc\u00ea trabalha com alguma plataforma aberta, como Java, as coisas come\u00e7am a ficar mais complicadas. Para come\u00e7ar, as bibliotecas que possu\u00edmos est\u00e3o bem distantes de serem apropriadas. Podemos criar planilhas e arquivos do Word, mas n\u00e3o podemos nos aprofundar muito na gera\u00e7\u00e3o destes documentos. Se voc\u00ea quiser, por exemplo, incluir um gr\u00e1fico em uma planilha (foi o meu caso), ter\u00e1 de primeiro criar um documento de modelo, incluir no mesmo suas s\u00e9ries, o gr\u00e1fico em quest\u00e3o, definir o n\u00famero de ocorr\u00eancias e, posteriormente, programaticamente, simplesmente substituir o valor destas c\u00e9lulas. Limita\u00e7\u00e3o total.<\/p>\n

H\u00e1 ainda problemas provenientes de optar-se pela automa\u00e7\u00e3o: para come\u00e7ar, seu cliente ter\u00e1 de ter o Microsoft Office instalado (traduzindo: Linux est\u00e1 fora da jogada). Isto sem mencionar que a gera\u00e7\u00e3o de documentos via automa\u00e7\u00e3o \u00e9 leeeenta.\u00a0<\/p>\n

E a raz\u00e3o pela qual as bibliotecas para gera\u00e7\u00e3o deste tipo de documentos ser t\u00e3o limitada \u00e9 simples: quase tudo o que sabemos sobre o formato Microsoft Office at\u00e9 agora \u00e9 a partir de engenharia reversa. S\u00f3 neste ano a Microsoft liberou a especifica\u00e7\u00e3o destes formatos, sendo assim, ainda n\u00e3o deu tempo para estas bibliotecas compreenderem de fato como s\u00e3o estruturados estes arquivos. Claro, h\u00e1 tamb\u00e9m o OOXML, mas caso optemos por este formato, novamente estaremos nos prendendo a um \u00fanico fornecedor. A solu\u00e7\u00e3o, portanto, consiste em buscar um formato alternativo para se gerar documentos. \u00c9 quando o OpenDocument entra em cena.<\/p>\n

OpenDocument consiste em um padr\u00e3o independente de fornecedor e 100% aberto para representar arquivos de escrit\u00f3rio. Se \u00e9 100% aberto, isto significa que qualquer um pode conhecer sua estrutura e, com base na mesma, criar documentos neste formato. E se \u00e9 independente de fornecedor, n\u00e3o precisamos nos preocupar se amanh\u00e3 existir\u00e1 um OpenOffice ou n\u00e3o. Nossos documentos ser\u00e3o suportados por outro fornecedor sem problemas, com 100% (ao menos em teoria) de compatibilidade. O mesmo n\u00e3o pode ser dito dos seus arquivos do Office.\u00a0<\/p>\n

Do ponto de vista do desenvolvedor, isto equivale a liberdade total. Ao adotar-se o padr\u00e3o ODF, o desenvolvedor n\u00e3o precisa se preocupar com o fato de seus clientes possuirem ou n\u00e3o o Microsoft Office. N\u00e3o \u00e9 necess\u00e1rio se preocupar com o fato de sua biblioteca suportar os recursos x,y ou z do formato, pois caso a mesma n\u00e3o possua este suporte, editar estes arquivos \u00e9 extremamente simples. Afinal de contas, basicamente, consistem em arquivos XML! E o melhor: trata-se de uma tecnologia REALMENTE gratuita.\u00a0<\/p>\n

Antes da cria\u00e7\u00e3o do formato OpenDocument, se algu\u00e9m quisesse criar uma suite de produtividade, teria de gastar uma fortuna com o desenvolvimento de seu pr\u00f3prio formato, al\u00e9m de fornecer suporte aos demais formatos utilizados pelas demais suites. Hoje, este custo diminuiu absurdamente, uma vez que n\u00e3o \u00e9 mais necess\u00e1rio investir no desenvolvimento de formatos propriet\u00e1rios. Basta seguir o padr\u00e3o definido pelo comit\u00ea respons\u00e1vel pelo desenvolvimento do padr\u00e3o. E se quiser incluir algo espec\u00edfico da sua aplica\u00e7\u00e3o? No problem! O padr\u00e3o OpenDocument j\u00e1 prev\u00ea estas necessidades e propicia aos desenvolvedores lidar com estas peculiaridades sem denegrir o padr\u00e3o. Sendo assim, \u00e9 \u00f3bvio que o formato ser\u00e1 o futuro, correto?<\/p>\n

E aqui entra a minha preocupa\u00e7\u00e3o. Mesmo com todas estas vantagens, n\u00e3o vejo muitos desenvolvedores (ao menos aqui no Brasil) se interessarem pelo formato. Ao buscar informa\u00e7\u00f5es no GUJ (neste link h\u00e1 a busca pelo formato ODF)<\/a>, por exemplo, a respeito da gera\u00e7\u00e3o de documentos no formato ODF, fiquei besta ao perceber qu\u00e3o poucas s\u00e3o as d\u00favidas. A maior parte dos posts diz respeito a not\u00edcias relacionadas, Ao postar<\/a> no f\u00f3rum sobre o projeto ODFEasy, fiquei chocado ao notar que s\u00f3 obtive UMA resposta! O que me fez parar para pensar sobre a real necessidade do projeto.\u00a0<\/p>\n

Ao que tudo indica, a comunidade de desenvolvedores n\u00e3o encontra-se atenta para este formato. Basta observar qu\u00e3o poucas s\u00e3o as bibliotecas existentes hoje para a gera\u00e7\u00e3o de documentos. Ao navegar pela mail list do projeto ODF Toolkit (que visa a cria\u00e7\u00e3o de ferramentas que possibilitem a gera\u00e7\u00e3o de documentos ODF via c\u00f3digo), percebe-se que n\u00e3o \u00e9 uma lista t\u00e3o ativa quanto deveria ser. Sinceramente, a impress\u00e3o que tenho \u00e9 a de que todos est\u00e3o esperando que algo apare\u00e7a para facilitar a tarefa, por\u00e9m poucos de fato fazem alguma coisa a respeito. Claro: h\u00e1 tamb\u00e9m o fato de hoje o Microsoft Office ser dominante, e que nossos clientes de fato querem arquivos do Office, e n\u00e3o do OpenOffice, por\u00e9m, conv\u00e9m mencionar que isto \u00e9 o AGORA. Se nada for feito, iremos ter os problemas que citei acima indefinidamente.<\/p>\n

Dado que estes problemas s\u00e3o percebidos mais claramente por desenvolvedores, e n\u00e3o por usu\u00e1rios finais, cabe a n\u00f3s fazer algo a respeito, buscando conhecer melhor o formato, criando ferramentas que facilitem a cria\u00e7\u00e3o de documentos e, principalmente, expondo aos nossos clientes os ganhos provenientes da ado\u00e7\u00e3o do formato.\u00a0<\/p>\n

No que diz respeito \u00e0 computa\u00e7\u00e3o pessoal\/corporativa, existem os seguintes pilares:<\/p>\n

\u00a0<\/p>\n