Introdução

Recentemente, eu comentava no Twitter sobre sistemas de preparação de documentos e a arte de produzir documentação de qualidade. Gostaria de aproveitar para desenvolver uma tangente sobre um assunto tão fascinante, agora longe das limitações e distrações típicas de uma rede social.

Para contextualização, eu comentava que, apesar de ter adquirido um certo nível de proficiência com LaTeX — suficiente para permitir que eu elaborasse uma série de trabalhos e atividades na universidade, para desespero de colegas de humanas —, sempre flertei com outros sistemas, sem nunca estudá-los em profundidade, como Lout, GNU roff e GNU Texinfo. Especialmente sobre os dois últimos, considero que são o perfeito exemplo do tipo de software maduro, poderoso e subestimado que acompanha a maioria das distribuições Linux.

Sistemas de preparação de documentos nada mais são do que programas que facilitam o processo de composição tipográfica, sendo uma das aplicações clássicas para um sistema Unix ou Unix-like. Estes programas, muito antes da popularização de sistemas operacionais de qualidade questionável ou mesmo da viabilidade massificada de interfaces gráficas, já eram capazes de auxiliar na produção de documentação técnica de alta complexidade.

Processadores de texto ≠ preparadores de documentos

Sistemas de preparação de documentos não devem ser confundidos com processadores de texto convencionais, como o antigo WordPerfect, que perdeu sua força comercial à medida que a Microsoft adotava práticas desonestas para promover a utilização do Microsoft Windows, ou o Microsoft Word, que continua a ser um dos processadores de texto mais populares — e cuja popularização, obviamente, se entrelaça com a desonestidade comercial da Microsoft.

Podemos imaginar um sistema de preparação de documentos como um conjunto de ferramentas que, dentre outras atividades, desempenha a interpretação de arquivos de texto que possuem não só o conteúdo dos documentos, mas marcações que determinam como o processamento deve ser realizado. Em outras palavras, cada preparador de documentos é basicamente um compilador, que interpreta código-fonte e, a partir dele, produz um documento formatado, que pode ser impresso ou visualizado.

Enquanto um processador de texto costuma adotar uma abordagem WYSIWYG (do inglês “what you see is what you get” ou “o que você vê é o que você obtém”, em tradução livre para o português), um preparador de documentos é, no máximo, WYSIWYM (do inglês “what you see is what you mean” ou “o que você vê é o que você quer dizer”, em tradução livre para o português). Trata-se de uma diferença de paradigma bastante radical, que afeta completamente a interação humano-máquina, uma vez que modifica a abstração em relação ao processo de construção de um documento.

Enquanto o processador de texto é mais intuitivo, principalmente para realização de tarefas simples, como a redação de documentos de poucas páginas (cartas, receitas, memorandos, comunicados), sem necessidade de formatação rigorosa ou coesa, um sistema de preparação de documentos pode facilitar a construção de documentos longos, com centenas ou milhares de páginas (livros, manuais, guias), e cuja formatação não pode apresentar inconsistências, nem demandar elevado microgerenciamento.

Processadores de texto deveriam ser evitados

Enquanto um preparador de documentos pode ser utilizado na produção de documentos curtos e simples, a recíproca não é completamente verdadeira quando se trata de elaborar documentos longos e complexos utilizando um processador de texto.

A construção de documentos complexos em um processador de texto, frequentemente, exige o domínio de todo o conjunto de funcionalidades que não é imediatamente óbvio, muito menos garantidamente consistente ou robusto, tais como seções, estilos e códigos de campo, sendo muito mais difícil garantir coesão e estabelecer padrões, uma vez que há muitos elementos invisíveis ou ofuscados dentro do arquivo utilizado pelo processador de texto. Não raramente, o processador de texto impõe severas restrições de funcionalidade ou de desempenho, sacrificando a produtividade e a saúde mental do usuário.

Na minha opinião, a intuitividade e facilidade iniciais de um processador de texto se transformam numa armadilha à medida que a complexidade aumenta, o que se traduz, no caso de um empreendimento, em perda de tempo e dinheiro. A interface gráfica e a amigabilidade parecem contribuir para que se subestime (ou se elimine completamente) o treinamento das partes envolvidas na elaboração de documentos, ou seja, a eliminação ou redução de um custo acaba se transformando numa economia burra, que em algum momento, acarreta uma série de problemas futuros (muitos deles difíceis de prever).

Contra a cristalização de más práticas, eu acredito fortemente que processadores de texto deveriam ser evitados sempre que possível. Considero de bom tom restringir a utilização de processadores de texto a documentos simples ou a etapas intermediárias, tais como a escrita de rascunhos, devidamente acompanhadas de verificação ortográfica e gramatical, para fragmentos de documentos.

Motivações para escrita deste artigo

Na realidade, decidi escrever este artigo porque achei que sistemas de preparação de documentos são o perfeito exemplo de um choque de paradigma que deveria ser encarado de outra maneira: não como um choque ameaçador ou uma barreira intransponível, mas como uma alavanca para redesenhar (e, eventualmente, eliminar) processos ineficientes, normalmente, baseados em soluções proprietárias.

Muitas vezes, estive envolvido em longas e infrutíferas discussões que teorizavam a migração de ambientes baseados no Microsoft Windows para alguma distribuição Linux (neste caso, a distribuição não é relevante) e, quando olho para o passado, percebo que muitas das discussões não esboçaram preocupação com o tipo de tarefa que seria desempenhada, nem, principalmente, com a tomada de decisão que seria feita — decisão esta que pouco ou nada dependia somente do sistema operacional.

Quando olho para os quase quinze anos de experiências profissionais que acumulo, acredito que a migração para software livre não deveria ser baseada numa noção rasa de clonagem de funcionalidades. Hoje percebo, que, quando a migração se baseia na busca por um “clone gratuito do Windows”, mais uma vez, a figura da economia burra, que tenta eliminar ou minimizar a necessidade de treinamento, acaba surgindo.

Lembro-me ainda que, quando eu comecei a me aventurar no universo do software livre/de código aberto, no final dos anos 1990, tive bastante dificuldade para entender como fazer as coisas que eu já fazia no MS-DOS e no Windows. Ninguém me explicou que, embora o principal pacote para automação de escritórios da época, StarOffice, não fosse viável para ser executado no meu 486 DX-4, eu ainda poderia utilizar LaTeX, Lout ou Groff para elaborar documentos com qualidade superior àquela entregue pelo Microsoft Word, por exemplo.

A passagem para a década de 2000 não foi melhor, pelo que me recordo. Abordagens que negligenciavam programas como Ledger ou hledger (sistemas de contabilidade baseada em arquivos de texto) e Org Mode (sistema para anotações, planejamento e produção de documentos dentro do editor Emacs, também baseado em arquivos de texto), continuaram a reforçar o mesmo tipo de discussão preguiçosa quando o assunto envolvia migrações completas do Windows para o Linux.

Acredito que clonar um programa como o Word pode não bastar, tanto porque o clone continuaria sendo um clone, apresentando idiossincrasias próprias, quanto porque a disputa acabaria se dando sobretudo na arena da redução de custos, o que, por si só, empobreceria as possibilidades e criaria um ambiente pouco afeito às transformações possíveis com um esforço migratório.

Nada contra softwares como o LibreOffice Writer ou o SoftMaker TextMaker — eu utilizo e gosto de ambos —, para citar duas alternativas ao Microsoft Word e permanecer no mesmo exemplo, mas é preciso ser pragmático: nenhuma delas é o Word e, principalmente, nenhuma delas se propõe a solucionar os problemas associados ao uso do Word, porque, no final das contas, ambas alternativas continuam sendo processadores de texto.

Conclusão

Há algum tempo, tenho flertado com a ideia de desenvolver outro subsite no domínio caiocesar.org. Minha ideia seria oferecer uma espécie de guia que abordasse a migração do Windows para Linux de forma completamente diferente: sem abraçar o mundo, sem tratar a audiência como mentecapta e, principalmente, sem um tom genérico e repleto de superficialidade, afinal, eu só gosto de produzir conteúdo que envolve o mínimo de skin in the game da minha parte.

Artigos como este são exercícios que me ajudam a pensar em formatos, temas, programas, soluções etc. Quando eu penso no emprego de software livre, tento fugir de lugares-comuns, como são aqueles que relegam soluções baseadas em Linux a setores de infraestrutura (como servidores) ou embarcados (como roteadores ou mesmo smartphones). Creio que, com a experiência e conhecimento que tenho acumulado, eu poderia escrever um guia diferente, que trata Linux mais como um Unix-like e menos como uma alternativa barata ao Windows, menos como um sistema para quem procura um desktop e mais para quem precisa de uma workstation.

Falar de sistemas de preparação de documentos, questionando abertamente a hegemonia dos processadores de texto, é o perfeito exemplo de como o guia poderia ser orientado. O marasmo das listinhas hipócritas de softwares cujo autor jamais tentou utilizar em aplicações práticas, seria substituído por uma abordagem casuísta, oferecendo possibilidades concretas dentro de um recorte específico.