As duas respostas mais óbvias são estas: os fornecedores negligenciaram o formato, tratando-o como uma reflexão tardia, ou estão trabalhando silenciosamente para desacreditar a própria ideia de interoperabilidade transparente, através do suporte tão ruim que demonstra o formato “não funciona”.
Ambas as respostas são muito simplistas. A realidade é que três mecanismos distintos estão em ação, aplicando-se a diferentes fornecedores em diferentes proporções e, finalmente, convergindo para o mesmo resultado.
Um desafio que não é um desafio
Ler e escrever ODF fielmente, isoladamente, é genuinamente viável: o formato é completamente e abertamente especificado, e não há equivalente às notórias bandeiras de compatibilidade legada da OOXML, que se referem a comportamentos indocumentados de produtos antigos da Microsoft que só a Microsoft pode reproduzir.
Uma equipe de desenvolvimento competente é capaz de implementar o ODF corretamente com base apenas na especificação ODF.
Uma suíte de escritório, no entanto, não implementa um formato isoladamente: possui uma representação interna e in-memory do documento. Carregar um documento é um mapeamento nessa representação, e salvar um documento é um mapeamento dele.
A fidelidade é maior quando o modelo interno é congruente com o formato do documento. O modelo do LibreOffice é essencialmente ODF, e é por isso que, neste contexto, o ODF é genuinamente nativo.
Quando o modelo interno de uma suíte tem a forma de OOXML, o ODF deixa de ser nativo e se torna uma importação externa que deve ser convertida de e para uma representação construída para um formato diferente.
Pegue um recurso ODF que o OOXML não possui: o campo ODP que exibe o número total de slides. A parte instrutiva é que a informação em si não está faltando em um arquivo PPTX. O pacote enumera cada slide e a contagem está disponível para qualquer programa que o abra. O que OOXML não fornece nenhuma maneira de expressar é a afirmação de que este número é o total. Há um campo para o número de slide atual e nenhum para a contagem, e a própria orientação da Microsoft é digitar a figura em uma caixa de texto e mantê-la atualizada à mão, que é uma descrição precisa de não ter um campo. Cada solução alternativa publicada é uma macro ou um suplemento que computa o número uma vez e o grava como texto fixo.
Então, quando um arquivo ODP que carrega esse campo é aberto em um editor baseado em OOXML, o que é perdido não são os dados, mas a instrução. O número sobrevive. O fato de ter sido calculado não, e a partir desse momento o documento não sabe mais quanto tempo é.
A direção inversa falha mais silenciosamente e, portanto, pior. Uma contagem de slides exportada do Impress para o PPTX deve ser escrita como texto fixo, portanto, a apresentação está correta no dia em que é convertida e errada na primeira vez que um slide é adicionado ou removido. Um número que deixou de ser calculado, mas ainda parece plausível, é mais prejudicial do que uma lacuna visível, porque nada no documento sinaliza que ele precisa ser verificado.
Um editor baseado em ODF lida com o caso inverso de uma maneira totalmente diferente. Quando encontra um recurso presente em um formato e ausente do outro, ele deixa os dados de lado em vez de descartá-los e os restaura quando o documento retorna ao OOXML. No LibreOffice, esse mecanismo tem um nome, o saco de captura, e é uma parte documentada dos filtros de importação, em vez de um comportamento incidental.
A diferença não está na qualidade do filtro de importação, mas no fato de que a arquitetura foi projetada para manter o significado do outro formato.
Isso importa, porque significa que o apoio ruim do ODF em suítes baseadas em OOXML é amplamente superdeterminado antes mesmo da questão do motivo surgir. A dificuldade não é absoluta, mas em relação à arquitetura que o vendedor escolheu.
Três mecanismos
Primeiro: a aposta em um formato de referência. Algumas suítes não consideram o ODF, porque construíram sua proposta de valor no outro formato.
O OnlyOffice é o caso mais claro, porque foi construído em torno do OOXML e converte todos os outros formatos nesse modelo, então o ODF é um formato de importação e exportação de segunda classe por design.
WPS Office é um software criado para abrir arquivos docx, xlsx e pptx fielmente. Sua funcionalidade ODF deriva do suplemento do próprio projeto OpenXML da Microsoft e foi integrada ao aplicativo apenas em maio de 2022, como uma camada de conversão escrita para ODF 1.1, ou seja, para a revisão de 2007 do padrão. Quinze anos de atraso foram construídos no dia do lançamento.
O Google Workspace é uma variante da mesma lógica, em vez de uma exceção a ele. Seu modelo interno não é nem ODF nem OOXML, mas uma representação web proprietária, e ambos os formatos o alcançam através de uma camada de conversão. Para uma administração pública, a consequência é idêntica: o padrão aberto é um alvo de exportação, não o substrato em que o software pensa.
Para esses fornecedores, a ODF nunca fez parte da estratégia. Sua proposta é abrir documentos da Microsoft em algo diferente do Microsoft Office, e fazê-los parecer certos, então o suporte ODF ruim é a consequência direta da estratégia.
Segundo: subinvestimento deliberado. Esta é provavelmente uma causa que atravessa todo o setor de suítes de escritório. Embora o ODF seja mais fácil e barato de implementar corretamente, o processo ainda envolve desenvolvimento, garantia de qualidade e custos de manutenção e cronogramas, a fim de acompanhar um padrão em constante evolução.
Se os usuários de um fornecedor trocam principalmente arquivos docx, o valor comercial marginal do excelente suporte ODF é próximo de zero, então o ODF é implementado primeiro no nível mínimo e, em seguida, silenciosamente deixado para apodrecer.
A percepção de que o suporte do ODF não importa é em si uma consequência da dominância do mercado de uma única empresa, e seu efeito é duplo. O Lock-in torna-se um recurso de software que o mercado considera totalmente normal, e a ODF adquire uma reputação de fragilidade que nenhuma campanha deliberada foi necessária para produzir.
Terceiro: desqualificação deliberada. Este mecanismo é real, e diz respeito à própria Microsoft, com o Service Pack 2 para o Office 2007. O suporte ODF que enviou falhou em duas direções opostas ao mesmo tempo.
Ao ler uma planilha ODF produzida por outro aplicativo, o Excel silenciosamente retirou as fórmulas e manteve apenas o último valor que cada célula havia mantido, reduzindo o documento, na avaliação de Rob Weir na época, a uma mera “tabela de números” com a lógica de cálculo desaparecida. Ao escrever, o Excel colocou fórmulas em um namespace do Excel que não era o usado pelo OpenOffice e o outro aplicativo ODF nem o OOXML. Os aplicativos que verificaram o namespace rejeitaram o documento diretamente; aqueles que não verificaram ele exibiram um arquivo corrompido mostrando nem a fórmula nem o valor corretamente.
Este é um mecanismo de livro didático para desacreditar a interoperabilidade: atender a um requisito de formato com uma implementação que está em conformidade apenas no papel e produz arquivos visivelmente quebrados, demonstrando a cada observador que o ODF não funciona de fato.
Na época, a Microsoft argumentou que o padrão ODF não definia fórmulas de planilhas, que chegaram apenas com o ODF 1.2, e que, portanto, não havia referência a seguir. O argumento não sobrevive à resposta da própria Microsoft. Respondendo publicamente ao Weir, o evangelista da Microsoft, Doug Mahugh, estabeleceu os dois comportamentos lado a lado: diante da mesma sintaxe de fórmula não reconhecida, a IBM Lotus Symphony preservou a marcação de fórmulas, enquanto o Excel preservou os valores em cache. Nenhuma das aplicações tinha uma especificação a seguir. Só um tinha uma arquitetura com algum lugar para colocar o que não entendia.
Vale a pena notar o que o Excel manteve. Não a fórmula, mas seu último resultado, que é a mesma redução que vimos com a contagem de slides, em um aplicativo diferente. Um modelo moldado por OOXML retém o valor e perde a computação que o produziu, e um documento reduzido a seus últimos resultados é um documento que deixou de ser capaz de se corrigir.
Esse episódio tem dezessete anos, e seria fácil deixá-lo de lado como história. O Microsoft Office declara hoje suporte para o ODF 1.4. Mas o que melhorou é a conformidade nominal, não a arquitetura. O modelo interno ainda é OOXML, e cada documento ODF que passa por ele ainda é uma tradução.
A síntese
O apoio ruim do ODF não é um veredicto técnico sobre o formato, mas a forma visível de um mercado organizado em torno do domínio de um único fornecedor, e essa forma não surgiu por acaso.
Para as administrações públicas europeias, isso redefine a questão prática, porque os problemas de interoperabilidade que eles enfrentam quando tentam migrar para o ODF padrão aberto não são causados pelo ODF, que está totalmente pronto. Eles são evidências de que a maioria das ferramentas disponíveis foram projetadas para serem nativas do formato de outra pessoa, e que o único fornecedor com o poder de mudar essa situação repetidamente escolheu não fazer.
O estado precário do apoio do ODF no mercado não é uma razão para hesitar em adotar o padrão, mas a razão mais forte possível para mandá-lo, e para mandá-lo precisamente.
A questão que protege os documentos de um órgão público, e sua soberania sobre eles, não é se o ODF é suportado, mas se esse suporte é nativo, ou seja, se o próprio modelo interno do software é o padrão aberto, ou o padrão é meramente um elemento estranho dentro de um motor construído para outra coisa.
O formato do documento é o substrato da continuidade administrativa e da memória pública. Escolher ferramentas para as quais o padrão aberto é nativo não é uma preferência entre opções equivalentes, mas a diferença entre possuir seus documentos e alugar acesso a eles de quem controla o formato em que eles estão realmente escritos.
Comentários
Postar um comentário