Converter Markdown para Word parece algo "com um clique", mas os problemas surgem muitas vezes logo depois desse clique: o índice desaparece, as tabelas ficam desalinhadas, a hierarquia fica toda trocada. O problema, na maioria das vezes, não está na ferramenta, mas no facto de os requisitos não terem sido pensados antes da conversão. Encare cada conversão como um pequeno contrato —o que se dá, o que se pede, como validar — e o retrabalho reduz-se para metade. A seguir, usamos o assistente de escritório MuchSci como exemplo; a conversão de formatos e a composição tipográfica em chinês (tipo de letra Noto) são capacidades já disponíveis.
Primeira pergunta: o que se dá
Verifique o ficheiro de origem e não entregue um trabalho a meio:
l Imagens: caminho local ou ligação externa? As imagens com ligação externa perdem-se muito provavelmente após a conversão; guarde primeiro as imagens localmente e só depois as referencie;
l Tabelas: o cabeçalho está completo? Há células fundidas aninhadas? As tabelas Markdown têm funcionalidades limitadas; simplifique primeiro no ficheiro de origem as tabelas demasiado complexas;
l Níveis de título: foram usados corretamente # / ## / ###? Um "negrito usado como título" escrito à mão não entra no índice após a conversão.
A qualidade do ficheiro de origem determina o limite da conversão —a ferramenta pode organizar a estrutura, mas não consegue inventar o que não foi escrito.
Segunda pergunta: o que se pede
"Converter para Word" é uma instrução vaga, e instruções vagas dão à ferramenta liberdade para improvisar. Substitua-a por um pedido claro: "Converta este conteúdo Markdown numWord com índice, mantendo os níveis de título do primeiro ao terceiro e as tabelas tal como estão."
Há coisas que não precisa de dizer: a composição tipográfica em chinês já está configurada com o tipo de letra Noto, e a camada tipográfica é uma capacidade predefinida. Mas os requisitos estruturais — índice, hierarquia, números de página, que partes têm de ser mantidas tal como estão —só contam se forem ditos antecipadamente; alterar depois significa uma segunda ronda de retrabalho.
Figura 1 | À esquerda, o que diz; à direita, a estrutura que deveria receber.
Terceira pergunta: como validar
Quando receber o .docx, não o feche logo; verifique estes seis pontos:
1. O índice é gerado automaticamente e os números de página estão corretos;
2. Os níveis de título do primeiro ao terceiro correspondem corretamente;
3. As listas e a numeração são contínuas;
4. As tabelas não têm linhas desalinhadas nem linhas quebradas;
5. As imagens estão na posição original e não estão deformadas;
6. O tipo de letra é uniforme em todo o texto.
E se a validação não passar: volte a dar instruções com itens específicos — "a tabela do terceiro capítulo tem linhas desalinhadas, converta novamente essa secção" — é dez vezes mais eficaz do que dizer apenas "está errado". A direção em que a ferramenta corrige os erros depende da direção em que aponta o erro; quanto mais específico for o feedback, mais perto do produto final fica a segunda ronda.
Figura 2 | Lista de validação: assinale cada item e só depois entregue.
Este contrato não serve apenas para um cenário
O contrato das três perguntas é universal: Word / Excel / PPT para PDF (a segunda pergunta passa a ser "que páginas converter, é preciso comprimir?"), CSV para Excel (a segunda pergunta passa a ser "agrupar por quê?"), divisão e junção de documentos longos (a segunda pergunta passa a ser "com que granularidade dividir?"). O cenário muda, o contrato mantém-se —a diferença de eficiência nas tarefas de conversão nunca está na rapidez da ferramenta, mas em saber se os requisitos foram esclarecidos de uma só vez.