Automação da produção editorial

A automação da produção editorial organiza o artigo aceito como uma fonte estruturada a partir da qual são preparados PDF, HTML e XML JATS, em vez de refazer o mesmo conteúdo separadamente para cada saída. Reduz o trabalho repetitivo, mas não substitui a decisão editorial nem a revisão técnica.

Na prática da OJS ONE, uma marcação XML JATS para a SciELO feita à mão leva cerca de 4 horas por artigo; com a automação do Jatson leva minutos. O tempo real depende do estado do documento, de suas tabelas, figuras, referências e correções pendentes.

Automação da produção editorial: o que muda

Automatizar não é apertar um botão no final do processo. É preparar uma representação comum do artigo que conserva estrutura, metadados e relações entre suas partes: título, autoria, afiliações, resumo, seções, citações, referências, tabelas, figuras e notas.

O JATS usa etiquetas para descrever essa estrutura editorial. Sua biblioteca inclui um elemento específico para os metadados do artigo, chamado article-meta.[1] Na prática, essa fonte estruturada permite transformar a mesma informação em diferentes formatos de leitura sem transcrevê-la novamente do zero.

O objetivo prático é claro: que uma correção autorizada em uma afiliação, em uma legenda ou em uma referência seja aplicada na fonte editorial e depois chegue às saídas correspondentes. Se cada formato é mantido separadamente, a equipe precisa localizar a mudança em mais de um arquivo, verificar que não deixou versões diferentes e publicar de novo.

A automação também não significa que qualquer arquivo Word esteja pronto para ser convertido sem preparação. Um arquivo aceito pode conter estilos inconsistentes, citações sem resolver, tabelas que se cortam, imagens de baixa qualidade ou decisões editoriais ainda em aberto. O processo ganha velocidade quando identifica esses elementos antes de gerar as provas.

Uma fonte editorial comum evita refazer o artigo

A principal decisão é deixar de tratar o PDF, o HTML e o XML JATS como três encargos independentes. O PDF serve para download, circulação formal e impressão; o HTML permite a leitura direta na tela; o XML JATS conserva uma estrutura reutilizável para fluxos acadêmicos. Cada saída cumpre uma função, mas todas devem contar a mesma versão do artigo.

O PKP apresentou um roteiro para que o OJS trabalhe com conteúdo estruturado e exportações para HTML, PDF e JATS XML. É um planejamento de produto, não uma função que deva ser dada como disponível em uma instalação atual.[2] O sinal é relevante porque confirma a direção do fluxo: estruturar o conteúdo antes de convertê-lo para formatos de publicação.

Também existem ferramentas que separam importação, marcação semântica, pré-visualização e exportação. O JATS Studio descreve esse percurso e oferece tanto o uso do aplicativo quanto um serviço de marcação.[3] Isso não prova que uma ferramenta resolva por si só o fechamento editorial de uma revista; mostra que produzir formatos a partir de uma estrutura comum exige etapas e responsabilidades explícitas.

Para uma revista, a pergunta útil não é se deve ter XML a qualquer custo. É qual será sua fonte de verdade, quem pode modificá-la, que saída será gerada de novo depois de uma correção e como o pacote final é aprovado.

O trabalho que deixa de se repetir artigo a artigo

Um fluxo comum reduz tarefas de cópia, repasse e conciliação. Não elimina o trabalho editorial substantivo; evita repetir tarefas que já foram bem feitas uma vez.

As seguintes são perguntas de controle propostas, não resultados medidos:

• Repetir nomes, afiliações e informações de autor ao preparar saídas diferentes.
• Corrigir uma referência em uma saída, sem saber se a mesma correção chegou às demais.
• Ajustar manualmente títulos, hierarquias de seções ou legendas de figuras para cada formato.
• Enviar versões diferentes à diagramação, à marcação e à carga no OJS.
• Comparar provas no fechamento porque não existe registro de qual documento é a versão aprovada.

A solução não é automatizar uma cadeia desordenada. Primeiro defina um ponto de entrada: documento aceito, metadados completos, arquivos de figuras e autorização editorial. Depois atribua uma versão identificável e um canal para resolver consultas. Só então a produção pode transformar e propagar mudanças com rastreabilidade.

No Jatson, a OJS ONE recebe o artigo já aceito, seus metadados e recursos gráficos; em seguida produz e verifica PDF, HTML e XML JATS a partir de um fluxo comum. A revista conserva a aprovação das provas antes de publicar.[4] É pertinente quando a equipe quer evitar coordenar formatos com fornecedores ou arquivos separados, sem mudar seu processo de avaliação por pares.

Que decisões continuam sendo humanas

Uma automação bem desenhada libera tempo de tarefas repetitivas, não delega decisões que exigem critério editorial. Convém declarar desde o início que perguntas as pessoas responsáveis devem responder.

A revista deve aprovar a versão do conteúdo que entra em produção. Também deve resolver dúvidas sobre a forma correta de uma autoria, afiliação, nota de financiamento, citação, referência ou imagem. Nenhuma regra técnica pode decidir legitimamente uma ambiguidade do manuscrito por conta própria.

A revisão visual também continua sendo necessária. Uma tabela pode estar estruturada de forma válida e ser difícil de ler no celular. Fórmulas, tabelas largas e figuras com texto pequeno merecem um teste de leitura nas saídas reais. O controle não termina quando o XML passa em uma validação.

Separe três tipos de revisão:

1. Editorial: conteúdo aprovado, autorias, textos, traduções e decisões de estilo.
2. Técnica: estrutura, arquivos associados, identificadores, links e avisos do formato exigido.
3. De leitura: PDF, HTML e visualização de tabelas, figuras, fórmulas e referências no ambiente em que serão publicados.

A mesma pessoa pode realizar mais de um controle em uma revista pequena, mas o registro deve indicar o que revisou e o que ficou pendente. Assim não se apresenta um teste técnico como aprovação editorial.

Como redesenhar o fechamento editorial sem interromper a revista

Você pode adotar o fluxo de maneira gradual. Não é preciso redesenhar a avaliação por pares nem substituir o OJS para organizar a produção. Comece ao terminar a edição de conteúdo e antes de preparar as provas.

Use este percurso como base:

1. Feche o artigo de produção. Reúna documento aprovado, metadados confirmados, figuras, tabelas e permissões necessárias.
2. Normalize o insumo. Identifique estilos irregulares, referências incompletas, nomes ambíguos e arquivos faltantes antes de produzir.
3. Estruture uma fonte comum. Represente o conteúdo e os metadados para que as saídas venham da mesma versão.
4. Gere as provas. Produza PDF, HTML e XML JATS conforme o escopo definido para essa revista.
5. Revise as três camadas. Obtenha aprovação editorial, controle técnico e revisão de leitura.
6. Registre as correções. Toda correção posterior deve indicar o que mudou, quem a aprovou e que saídas foram regeneradas.
7. Publique e conserve o pacote. Carregue as versões autorizadas no OJS e mantenha a cópia identificável dos arquivos entregues.

Essa sequência serve tanto se a produção é feita internamente quanto se é contratada. Muda quem executa cada passo, não a necessidade de existir uma fonte controlada e uma aceitação documentada.

Diagrama próprio: o controle humano revisa conteúdo, qualidade e aprovação antes de publicar.

Controle de qualidade: o que você deve pedir antes de publicar

O pacote final deve permitir que a revista verifique o resultado, e não apenas receba arquivos anexos. Defina a evidência de encerramento antes de enviar o primeiro artigo.

Peça, no mínimo:

• Identificação da versão de entrada e data da aprovação editorial.
• PDF revisável e HTML acessível pelo caminho que o leitor usará.
• XML JATS junto com o relatório de validações ou avisos aplicados.
• Relação de figuras, tabelas, anexos e arquivos suplementares incluídos.
• Registro das consultas resolvidas e das correções incorporadas.
• Responsável por carregar o pacote no OJS e verificar a publicação.

Se o destino exige um perfil particular, descreva-o no encargo. Um XML JATS não é automaticamente equivalente a um pacote aceito por qualquer plataforma. Para fluxos SciELO, revise também o guia de erros de controle editorial em XML JATS: um arquivo estruturalmente válido pode conservar erros de conteúdo ou de metadados.

Erros comuns ao automatizar a produção editorial

O problema mais frequente é tratar a automação como substituta de uma rotina editorial. Evite estes atalhos:

• Converter um Word sem revisão prévia. A conversão pode conservar as inconsistências do insumo.
• Usar o PDF como fonte mestra. Se uma correção nasce na diagramação, será mais difícil propagá-la ao HTML e ao XML.
• Esconder as consultas de produção em e-mails dispersos. Conserve as decisões junto com a versão que as motivou.
• Aceitar apenas uma validação técnica. Revise também leitura, composição e consistência editorial.
• Separar formato e publicação como se não estivessem conectados. Defina quem carrega as provas, revisa links e confirma a disponibilidade no OJS.
• Apresentar a automação como garantia de indexação. A produção organizada ajuda a preparar arquivos, mas não decide a avaliação da SciELO nem de outro índice.

Perguntas frequentes

A automação editorial substitui a diagramação?

Não necessariamente. Ela pode gerar um PDF a partir de uma estrutura comum e de um modelo, mas a revista continua definindo sua identidade visual, revisando a legibilidade e autorizando as provas. Um modelo personalizado também exige decisões de design e controle editorial.

Posso automatizar apenas HTML e PDF sem produzir XML JATS?

Sim, o escopo depende do seu objetivo e do fluxo escolhido. O roteiro do PKP chega a contemplar um HTML intermediário para algumas exportações.[2] Se depois você precisar de XML JATS para um circuito específico, convém resolvê-lo desde o desenho da fonte editorial e não acrescentá-lo ao fechamento como uma tarefa isolada.

O que acontece quando chega uma correção depois de aprovar as provas?

Registre a mudança, obtenha sua autorização e regenere as saídas afetadas a partir da fonte comum. Depois verifique que o pacote anterior não continue disponível por engano no OJS ou nos arquivos de trabalho.

Leve a automação a um fluxo editorial verificável

Se a sua revista acumula correções entre arquivos, parte da solução está na sequência de trabalho e não apenas na ferramenta. Defina primeiro que informação entra aprovada, que controles cada artigo exige e quem aceita as saídas.

O Jatson é o serviço da OJS ONE para produzir PDF, HTML e XML JATS a partir do artigo aceito. Na prática da OJS ONE, a marcação manual pode levar cerca de 4 horas por artigo e a automação minutos; o resultado depende do insumo e das decisões pendentes. Revise o fluxo de produção editorial com o Jatson e avalie se ele se ajusta ao fechamento da sua revista.

Fontes

1. Element: Article Metadata, NISO JATS Version 1.4 — consultado em 2026-10-22.
2. Article Production in PKP Software: Directions and Plans — consultado em 2026-10-22.
3. JATS Studio — consultado em 2026-10-22.
4. Produção editorial para periódicos OJS | OJS One Jatson — consultado em 2026-10-22.