↓ Arquivos ↓

Categorias → ODF

ODF Easy 0.2 lançado – gerar planilhas do OpenOffice está ficando mais fácil!

Acabo de lançar a versão 0.2 do ODF Easy. Nesta nova versão, finalmente inclui suporte a alguma formatação de células (cor de fundo, fontes, bordas, etc.) e iniciei o desenvolvimento do suporte à criação de gráficos também.

Espero que com este projeto, possa ajudar aqueles que passaram pelas mesmas dificuldades que passei ao tentar gerar documentos ODF em Java.

Para facilitar a divulgação do projeto, criei um site para o mesmo: http://odfeasy.itexto.com.br

Por que o OpenDocument Format (ODF) é importante (e porque fico assustado com o quão negligenciado o mesmo é)?

É interessante se fazer a pergunta: por que x é importante? Antes de iniciar o desenvolvimento do projeto ODFEasy, sabia que ODF seria algo “importante”, mas nunca havia sentido na pele a sua necessidade. Afinal de contas, se já 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.

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

Já se você trabalha com alguma plataforma aberta, como Java, as coisas começam a ficar mais complicadas. Para começar, as bibliotecas que possuímos estão bem distantes de serem apropriadas. Podemos criar planilhas e arquivos do Word, mas não podemos nos aprofundar muito na geração destes documentos. Se você quiser, por exemplo, incluir um gráfico em uma planilha (foi o meu caso), terá de primeiro criar um documento de modelo, incluir no mesmo suas séries, o gráfico em questão, definir o número de ocorrências e, posteriormente, programaticamente, simplesmente substituir o valor destas células. Limitação total.

Há ainda problemas provenientes de optar-se pela automação: para começar, seu cliente terá de ter o Microsoft Office instalado (traduzindo: Linux está fora da jogada). Isto sem mencionar que a geração de documentos via automação é leeeenta. 

E a razão pela qual as bibliotecas para geração deste tipo de documentos ser tão limitada é simples: quase tudo o que sabemos sobre o formato Microsoft Office até agora é a partir de engenharia reversa. Só neste ano a Microsoft liberou a especificação destes formatos, sendo assim, ainda não deu tempo para estas bibliotecas compreenderem de fato como são estruturados estes arquivos. Claro, há também o OOXML, mas caso optemos por este formato, novamente estaremos nos prendendo a um único fornecedor. A solução, portanto, consiste em buscar um formato alternativo para se gerar documentos. É quando o OpenDocument entra em cena.

OpenDocument consiste em um padrão independente de fornecedor e 100% aberto para representar arquivos de escritório. Se é 100% aberto, isto significa que qualquer um pode conhecer sua estrutura e, com base na mesma, criar documentos neste formato. E se é independente de fornecedor, não precisamos nos preocupar se amanhã existirá um OpenOffice ou não. Nossos documentos serão suportados por outro fornecedor sem problemas, com 100% (ao menos em teoria) de compatibilidade. O mesmo não pode ser dito dos seus arquivos do Office. 

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

Antes da criação do formato OpenDocument, se alguém quisesse criar uma suite de produtividade, teria de gastar uma fortuna com o desenvolvimento de seu próprio formato, além de fornecer suporte aos demais formatos utilizados pelas demais suites. Hoje, este custo diminuiu absurdamente, uma vez que não é mais necessário investir no desenvolvimento de formatos proprietários. Basta seguir o padrão definido pelo comitê responsável pelo desenvolvimento do padrão. E se quiser incluir algo específico da sua aplicação? No problem! O padrão OpenDocument já prevê estas necessidades e propicia aos desenvolvedores lidar com estas peculiaridades sem denegrir o padrão. Sendo assim, é óbvio que o formato será o futuro, correto?

E aqui entra a minha preocupação. Mesmo com todas estas vantagens, não vejo muitos desenvolvedores (ao menos aqui no Brasil) se interessarem pelo formato. Ao buscar informações no GUJ (neste link há a busca pelo formato ODF), por exemplo, a respeito da geração de documentos no formato ODF, fiquei besta ao perceber quão poucas são as dúvidas. A maior parte dos posts diz respeito a notícias relacionadas, Ao postar no fórum sobre o projeto ODFEasy, fiquei chocado ao notar que só obtive UMA resposta! O que me fez parar para pensar sobre a real necessidade do projeto. 

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

Dado que estes problemas são percebidos mais claramente por desenvolvedores, e não por usuários finais, cabe a nós fazer algo a respeito, buscando conhecer melhor o formato, criando ferramentas que facilitem a criação de documentos e, principalmente, expondo aos nossos clientes os ganhos provenientes da adoção do formato. 

No que diz respeito à computação pessoal/corporativa, existem os seguintes pilares:

 

  • Sistemas operacionais: temos o Linux, Solaris, Mac OS e BSD brilhando aonde antes havia apenas Windows.
  • Bancos de dados: temos MySQL, PostgreSQL, Firebird, HSQLDB e diversos outros SGBDs que tornaram a compra de SGBDs proprietários algo do passado. 
  • Ferramentas de desenvolvimento: Java, C/C++, Perl e todas as linguagens abertas que, uma vez aprendidas, se mostram infinitamente superiores às ferramentas proprietárias que dominavam até então, como o Visual Studio, Delphi, etc.
  • Criação de documentos: temos o OpenOffice, e o Microsoft Office dominando TODO o mercado (causando os problemas que acima citei).

 

Como pode ser visto, três dos pilares já estão sólidos. Falta apenas um! Pessoas compram computadores hoje para dois propósitos: navegar na Internet (e esta sim é baseada em padrões abertos) e criar documentos. A partir do momento em que passarem a gerar documentos usando padrões abertos, não precisarão mais gastar 200,300,400,600 reais com Windows + 100 reais com anti-vírus. Poderão usar Linux, BSD, Solaris, Mac OS, o que quiserem.

E como consequência, nós, desenvolvedores, não ficaremos presos a uma única plataforma nem seremos limitados ao que o fornecedor da plataforma dominante QUER abrir ou não.

Como é um documento do OpenOffice (ODF) por dentro?

Nestes dias, nos quais venho me dedicando ao desenvolvimento do projeto ODFEasy, acabei por me encantar com o formato ODF. Sendo assim, nesta semana, pretendo começar a expor o seu interior. Para começar, irei expor aqui como é o interior destes arquivos.

Ao contrário do que podemos pensar a princípio, um documento gerado pelo OpenOffice não consiste em um monobloco binário no qual se encontram todas as informações referentes à formatação do mesmo, conteúdo, imagens, etc. Na realidade, um documento gerado pelo OpenOffice consiste em um arquivo compactado no formato zip, dentro do qual se encontram uma série de arquivos responsáveis por descrever a formatação do documento, além de, é claro, armazenar seu conteúdo.

Faça a seguinte experiência: gere um arquivo qualquer no OpenOffice e, em seguida, abra este arquvo com seu software de compactação/descompactação favorito e, em seguida, o descompacte em um diretório qualquer. Você verá um conteúdo semelhante ao exposto na imagem abaixo:

Só de se observar a estrutura dos arquivos, já começamos a ter uma noção sobre como é organizado um arquivo ODF. Cada arquivo, cujo próprio nome já nos diz, possui sua função:

content.xml - Armazena o conteúdo do documento, seja ele uma planilha, apresentação, texto, imagem ou outro tipo qualquer
styles.xml – Todas as formatações compartilhadas presentes no documento. As formatações são armazenadas em um arquivo separado visando, assim, separar o conteúdo da mesma, o que facilita bastante a manutenção dos documentos. Claro, é possível também armazenar alguma formatação no arquivo content.xml, porém, neste caso, normalmente são armazenadas somente formatações específicas de um trecho específico do documento.
mimetype - O arquivo mais simples. Contém apenas uma string que identifica o tipo do documento. Diz, por exemplo, se trata-se de um texto, planilha, desenho, etc.
meta.xml - O nome já entrega :) – Armazena meta informações sobre o documento, como por exemplo qual o seu autor, qual software foi o responsável pela geração do documento, etc.
settings.xml – Informações específicas da aplicação responsável por gerar o documento, como por exemplo posicionamento de janelas, configurações internas, etc. Aqui fica nítido um dos principais objetivos do formato OpenDocument: ao armazenar informações específicas de uma aplicação em um arquivo separado, garante-se assim que um aplicativo específico não venha a dominar o formato. 
Thumbnails - Trata-se de um diretório criado pelo próprio OpenOffice (não necessáriamente definido no padrão ODF). Como o próprio nome diz, armazena imagens responsáveis por disponibilizar uma pré-visualização do documento.
META-INF/manifest.xml - Dentro do diretório META-INF, há um arquivo chamado manifest.xml. Este arquvo contém uma lista de todos os documentos presentes no arquivo compactado. Ou seja, se você quiser que seu documento seja lido, este arquivo TEM de existir. :)
Configurations2 - Armazena qualquer configuração customizada definida pela aplicação responsável pela geração do documento.
Pictures -  Há também um diretório que não se encontra listado na imagem acima (mea culpa), chamado Pictures, responsável por armazenar todas as imagens contidas em um documento.

Sendo assim, neste primeiro post, podemos ver como é o interior de um arquivo gerado pelo OpenOffice. A partir daqui, irei expor as principais dificuldades que venho enfrentando na implementação do projeto ODFEasy. Tal como verão, nem tudo são flores ao mergulharmos no formato OpenDocument, porém, ainda é melhor do que ficarmos presos para sempre no formato do Office que, mesmo com a abertura atual, não é tão “aberto” assim como tentam nos convencer. ;)

ODF Easy 0.1 liberado. Facilitando a geração de documentos para o OpenOffice

Tal como mencionei no post anterior, iniciei o desenvolvimento de uma nova API para geração de arquivos no formato ODF (os arquivos com os quais o OpenOffice trabalha). Pois bem, acabo de liberar o primeiro release deste projeto.

Ainda é bastante rudimentar. Basicamente, permite aos usuários apenas criar novas planilhas e inserir algumas células (sem qualquer tipo de formatação ainda) nestas planilhas. Trata-se da versão 0.1 ainda (pré alfa). Para a versão 0.2, está prevista a inclusão de alguma formatação, além do início da inclusão de gráficos nas planilhas.

Para aqueles que se interessarem em participar do projeto, o código fonte (liberado sob a licença LGPL) pode ser baixado em http://sourceforge.net/projects/odfeasy/

Tal como mencionei no post anterior, a ODFEasy consiste em um layer alternativo para ser usado juntamente com o projeto ODFDOM. Sendo assim, para poder contribuir com o projeto, é necessário que você baixe o código fonte deste projeto (também disponível) no SourceForge (no mesmo link).

Gerando arquivos ODF com Java: anunciando o ODFEasy

Semana passada, em um de nossos projetos, precisamos gerar alguns gráficos no Excel usando Java. Não para nossa surpresa, o suporte a esta funcionalidade do formato Excel é extremamente limitada para aqueles que trabalham com Java. Basicamente, vimos duas opções:

  • Criar um modelo pré-definido com um gráfico já pré-criado e, em seguida, simplesmente preencher algumas células do gráfico em questão.
  • Utilizar uma biblioteca como o JExcel, que permite acesso via COM ao Excel, permitindo assim automatizar sua execução.

Para o nosso caso, dado que nossos gráficos serão criados dinâmicamente, a primeira opção foi fácilmente excluida. Isto porque o número de séries de nossos gráficos poderia sofrer inúmeras variações, isto sem mencionar do próprio tipo de gráfico a ser gerado.

A segunda, bem: será que valeria a pena jogar fora a portabilidade que ganhamos com Java? E outra: gerar arquivos do Excel via automação é extremanete leeeeento.

Sendo assim, optamos por adotar o formato ODF. Buscamos algumas bibliotecas e acabamos por optar pelo ODFDOM. A primeira vista, pareceu ser a solução ideal. Navegando rápidamente pela estrutura de classes, vimos todos os componentes de que precisávamos. Já na hora de usar a API…

As coisas nem de longe aparentavam ser tão fáceis assim. Na realidade, gerar arquivos ODF é muito mais complicado do que haviamos imaginado. isto porque a biblitoeca ODFDOM é fortemente focada no XML, e não no documento em si. Pela interface que possuimos com a biblioteca, o tempo inteiro acessamos nós em um documento XML, o que, convenhamos, nem de longe é a maneira mais simples de se visualizar o documento final que se visa criar via código.

(claro, sei que o projeto ainda está na versão 0.6.x, mas mesmo assim, para as nossas necessidades atuais, não é suficiente).

Como resultado, optamos por criar uma nova camada baseada no ODFDOM para a geração de arquivos neste formato. Por enquanto, estamos chamando esta nova API de ODFEasy. Esta possuirá uma interface voltada mais para a geração do documento em si. O código gerado por esta biblioteca, acreditamos, será muito mais simples de ser compreendido do que aquele que produzimos usando o ODFDOM. 

(Acredito que a existência de uma API simplificada como a ODFEasy seja essencial para a adoção bem sucedida do formato ODF. Só para lembrar, uma as principais razões pelas quais o Microsoft Office é adotado consiste justamente na facilidade que possuimos de gerar documentos programáticamente.  

E, convenhamos, a adoção do ODF trará ganhos para todos, visto que se trata de um formato do qual possuimos 100% de conhecimento a respeito, ao contrário do que ocorre com o Microsoft Office)

Inicialmente, nosso foco consiste na geração de planilhas (influenciado pela nossa necessidade atual) e gráficos. Posteriormente, conforme nossas necessidades venham a evoluir, pretendemos abranger outros tipos de documento.

O projeto ainda não possui um site (pretendo construi-lo no decorrer desta semana) para que possamos liberar o código fonte (cuja licença será a LGPL), mas já aproveito a ocasião para convidá-los a participar deste projeto, bastando para isto entrar em contato comigo a partir deste blog.

Sendo assim, nesta semana podem esperar mais posts sobre o desenvolvimento deste projeto neste blog (e, com isto, maiores informações sobre como é de fato o formato ODF).

Get Adobe Flash playerPlugin by wpburn.com wordpress themes