Editorial Production Automation

Editorial production automation organizes the accepted article as a structured source from which PDF, HTML and JATS XML are prepared, instead of redoing the same content separately for each output. It reduces repetitive work, but it does not replace the editorial decision or the technical review.

In OJS ONE's practice, JATS XML tagging for SciELO done by hand takes about 4 hours per article; with Jatson's automation it takes minutes. The actual time depends on the state of the document, its tables, figures, references and pending corrections.

Editorial production automation: what changes

Automating is not pressing a button at the end of the process. It is preparing a common representation of the article that keeps structure, metadata and the relationships between its parts: title, authorship, affiliations, abstract, sections, citations, references, tables, figures and notes.

JATS uses tags to describe that editorial structure. Its tag library includes a specific element for article metadata, called article-meta.[1] In practice, that structured source lets you transform the same information into different reading formats without transcribing it again from scratch.

The practical goal is clear: that an authorized correction to an affiliation, a caption or a reference is applied in the editorial source and then reaches the outputs that correspond. If each format is maintained separately, the team has to locate the change in more than one file, verify that it did not leave different versions and publish again.

Automation also does not mean that any Word file is ready to be converted without preparation. An accepted file may contain inconsistent styles, unresolved citations, tables that get cut off, low-quality images or editorial decisions that are still open. The process gains speed when it identifies those elements before generating the proofs.

A common editorial source avoids redoing the article

The main decision is to stop treating the PDF, the HTML and the JATS XML as three independent jobs. The PDF is for download, formal circulation and printing; the HTML allows reading directly on screen; the JATS XML keeps a structure that can be reused in academic workflows. Each output serves a function, but all must tell the same version of the article.

PKP has presented a roadmap for OJS to work with structured content and exports to HTML, PDF and JATS XML. It is product planning, not a feature that should be taken as available in a current installation.[2] The signal is relevant because it confirms the direction of the workflow: structure the content before converting it to publication formats.

There are also tools that separate import, semantic tagging, preview and export. JATS Studio describes that path and offers both use of the application and a tagging service.[3] This does not prove that a tool by itself solves a journal's editorial closing; it shows that producing formats from a common structure requires explicit stages and responsibilities.

For a journal, the useful question is not whether it should have XML at any cost. It is what its source of truth will be, who can modify it, which output will be regenerated after a correction and how the final package is approved.

The work that stops being repeated article by article

A common workflow reduces copying, handover and reconciliation tasks. It does not remove substantive editorial work; it avoids repeating tasks that were already done well once.

The following are proposed control questions, not measured results:

• Repeating names, affiliations and author information when preparing different outputs.
• Correcting a reference in one output without knowing whether the same correction reached the others.
• Manually adjusting titles, section hierarchies or figure captions for each format.
• Sending different versions to layout, tagging and upload to OJS.
• Comparing proofs at closing because there is no record of which document is the approved version.

The solution is not to automate a disorderly chain. First define an entry point: accepted document, complete metadata, figure files and editorial authorization. Then assign an identifiable version and a channel for resolving queries. Only then can production transform and propagate changes with traceability.

With Jatson, OJS ONE receives the already accepted article, its metadata and graphic resources; it then produces and verifies PDF, HTML and JATS XML from a common workflow. The journal keeps the approval of the proofs before publishing.[4] It is appropriate when the team wants to avoid coordinating formats with separate providers or files, without changing its peer review process.

Which decisions remain human

A well-designed automation frees time from repetitive tasks; it does not delegate decisions that require editorial judgment. It is worth stating from the start which questions the responsible people must answer.

The journal must approve the content version that enters production. It must also resolve doubts about the correct form of an authorship, affiliation, funding note, citation, reference or image. No technical rule can legitimately decide an ambiguity in the manuscript on its own.

Visual review also remains necessary. A table may be validly structured and still be hard to read on mobile. Formulas, wide tables and figures with small text deserve a reading test on the real outputs. The check does not end when the XML passes a validation.

Separate three types of review:

1. Editorial: approved content, authorship, texts, translations and style decisions.
2. Technical: structure, associated files, identifiers, links and warnings for the required format.
3. Reading: PDF, HTML and display of tables, figures, formulas and references in the environment where they will be published.

The same person may carry out more than one check in a small journal, but the record should indicate what they reviewed and what remained pending. That way a technical test is not presented as editorial approval.

How to redesign editorial closing without interrupting the journal

You can adopt the workflow gradually. There is no need to redesign peer review or replace OJS to bring order to production. Start when content editing is finished and before preparing the galleys.

Use this path as a base:

1. Close the production article. Gather the approved document, confirmed metadata, figures, tables and necessary permissions.
2. Normalize the input. Identify irregular styles, incomplete references, ambiguous names and missing files before producing.
3. Structure a common source. Represent the content and metadata so that the outputs come from the same version.
4. Generate the proofs. Produce PDF, HTML and JATS XML according to the scope defined for that journal.
5. Review the three layers. Obtain editorial approval, technical control and a reading review.
6. Record corrections. Every later correction must indicate what changed, who approved it and which outputs were regenerated.
7. Publish and keep the package. Upload the authorized versions to OJS and keep an identifiable copy of the files delivered.

This sequence works whether production is done in-house or contracted. What changes is who carries out each step, not the need for a controlled source and a documented acceptance.

Our own diagram: human control reviews content, quality and approval before publishing.

Quality control: what to ask for before publishing

The final package must let the journal check the result, not just receive attached files. Define the closing evidence before sending the first article.

Ask for, at a minimum:

• Identification of the input version and the date of editorial approval.
• A reviewable PDF and an HTML accessible through the path the reader will use.
• JATS XML together with the report of validations or warnings applied.
• A list of the figures, tables, appendices and supplementary files included.
• A record of resolved queries and incorporated corrections.
• The person responsible for uploading the package to OJS and checking the publication.

If the destination requires a particular profile, describe it in the engagement. A JATS XML is not automatically equivalent to a package accepted by any platform. For SciELO workflows, also review the guide on editorial control errors in JATS XML: a structurally valid file can still contain content or metadata errors.

Common mistakes when automating editorial production

The most frequent problem is treating automation as a replacement for an editorial routine. Avoid these shortcuts:

• Converting a Word file without prior review. The conversion can keep the inconsistencies of the input.
• Using the PDF as the master source. If a correction originates on the layout, it will be harder to propagate to the HTML and the XML.
• Hiding production queries in scattered emails. Keep the decisions together with the version that prompted them.
• Accepting only a technical validation. Also review reading, composition and editorial consistency.
• Separating format and publication as if they were not connected. Define who uploads the galleys, checks links and confirms availability in OJS.
• Presenting automation as a guarantee of indexing. Orderly production helps prepare files, but it does not decide the evaluation by SciELO or any other index.

Frequently asked questions

Does editorial automation replace layout?

Not necessarily. It can generate a PDF from a common structure and a template, but the journal still defines its visual identity, reviews legibility and authorizes the proofs. A custom template also requires design decisions and editorial control.

Can I automate only HTML and PDF without producing JATS XML?

Yes, the scope depends on your goal and the workflow chosen. PKP's roadmap even contemplates an intermediate HTML for some exports.[2] If you will later need JATS XML for a specific circuit, it is better to solve it from the design of the editorial source rather than add it at the end as an isolated task.

What happens when a correction arrives after the proofs are approved?

Record the change, obtain its authorization and regenerate the affected outputs from the common source. Then check that the previous package is not still available by mistake in OJS or in the working files.

Bring automation to a verifiable editorial workflow

If your journal accumulates corrections across files, part of the solution lies in the work sequence and not only in the tool. First define what information enters approved, what checks each article requires and who accepts the outputs.

Jatson is OJS ONE's service for producing PDF, HTML and JATS XML from the accepted article. In OJS ONE's practice, manual tagging can take about 4 hours per article and automation minutes; the result depends on the input and on pending decisions. Review the editorial production workflow with Jatson and assess whether it fits your journal's closing.

Sources

1. Element: Article Metadata, NISO JATS Version 1.4 — accessed 2026-10-22.
2. Article Production in PKP Software: Directions and Plans — accessed 2026-10-22.
3. JATS Studio — accessed 2026-10-22.
4. Editorial production for OJS journals | OJS One Jatson — accessed 2026-10-22.