OJS 3.6 Editorial Production: In-House or Specialized

OJS 3.6 Editorial Production: In-House or Specialized

OJS 3.6 editorial production lets you work from structured HTML to generate HTML, PDF and JATS XML galleys inside the platform. That can simplify a journal's closing process; it does not remove the need to decide who prepares the input, resolves exceptions and approves each delivery.[1]

The useful decision is not choosing between OJS or a service. It is defining which stretch your team can take on with control and which stretch is better assigned to specialized production, depending on volume, complexity and the level of control you require. To set this decision against repetitive tasks, also see this guide on editorial production automation.

Original diagram. One representative article lets you compare responsibilities and evidence before committing a full issue.

OJS 3.6 editorial production: what the platform integrates

OJS 3.6 proposes a common source for publication outputs. PKP describes an integrated text editor that saves the body HTML as the canonical source and lets you generate HTML, PDF and JATS XML when the editor activates it.[1]

The relevant change is traceability. If the body of the article and its metadata are ready inside the workflow, a correction can reach the galleys without rebuilding each file separately. The journal keeps the submission context, editorial control and publication in the same system.

This route has limits worth considering from the start. PKP states that the editor shares the main content of the article, not the cover material; it also acknowledges that complex or atypical styles may not transform perfectly.[1][2] For that reason, integrated generation does not replace visual review of wide tables, formulas, images, notes or layouts that depend on a very particular editorial template.

Nor does it oblige you to abandon the current workflow. PKP keeps use of the editor available as an option and states that the traditional workflow with desktop tools and third-party services remains available.[1] Integration widens the production alternatives; it does not turn one alternative into the rule for every journal.

OJS 3.6 and a specialized service are complementary

Complementarity appears when you separate platform, editorial source and production execution. OJS can be the place where submission, review, editorial decisions and publication are managed. A service can come in after acceptance to prepare assets, apply a template, carry out checks and return files ready to upload.

PKP also distinguishes a JATS-centered workflow that runs outside OJS: external services produce JATS from DOCX when the manuscript is accepted, and that JATS serves as the source for HTML and PDF. That workflow is not included in OJS 3.6.[2] The distinction helps avoid a wrong expectation: producing JATS from HTML inside OJS and managing external JATS production are different routes, even though both seek consistency across formats.

Jatson is presented as a production layer after the accepted article: it receives source content, structures it, validates it and converts it into JATS XML, editorial PDF and Scholarly HTML to publish in OJS.[5] In its general offering, the journal keeps the editorial decision and the service takes on production.[4] That division can coexist with OJS 3.6 if a source of truth, a delivery version and an owner for corrections are defined.

There is no universal answer. A journal with a simple template, trained staff and time to review proofs may favor in-house production. Another that needs to concentrate multi-format preparation or resolve exceptions recurrently may evaluate specialized support. The key is to compare the real work, not just the function available on screen.

Decision matrix: in-house, specialized or mixed production

Use this matrix in a production meeting. Mark the option that describes your current operation and note one piece of evidence: an article sample, a record of corrections or an approved proof.

Criterion	In-house production with OJS 3.6	Specialized service	Mixed scheme
Working source	The team maintains HTML and metadata in OJS.	The service receives the final file and the agreed inputs.	OJS concentrates the workflow; the service prepares defined deliverables.
Available team	There is an editor and technical support with time for testing.	Internal capacity is limited or variable.	The team reviews and approves; execution is concentrated outside.
Design and exceptions	The template is stable and exceptions are manageable.	There is layout, tables, formulas or requirements that demand dedicated review.	Regular pieces go one way and exceptional ones another.
JATS XML	The integrated output and the journal's own control are enough.	An external delivery with agreed editorial and technical scope is required.	The internal output is compared with an external sample before the workflow is fixed.
Later corrections	The team can regenerate and verify galleys inside OJS.	The agreement defines how a correction is requested, versioned and delivered.	OJS records the decision; the service updates the assets it was commissioned for.
Closing control	The journal can take on a checklist and approval of each format.	The journal approves proofs; the provider documents checks and delivery.	Owners are assigned by format and by version.

The chosen column is not permanent. Review it when the template, frequency, team or indexing requirements change. It is wise to test a representative sample before committing a full issue: an article with a table, figure, references and elements that tend to raise questions.

What the internal team should take on

The internal team keeps the decisions that require editorial authority. Before sending an article to production, it must confirm the approved version of the text, authorship, affiliations, title, abstract, funding, figures, permissions and references. If there is doubt about the content, it must be resolved before the proof is closed.

It must also define the acceptance criterion. A short checklist may include:

• identified and authorized manuscript version;
• metadata checked against the editorial version;
• graphic files with defined name and location;
• agreed template, language and output formats;
• owner who approves PDF, HTML and JATS XML;
• channel and internal deadline for comments;
• record of the published version and of later corrections.

In OJS 3.6, the team must decide whether it will edit the body inside the integrated editor, who will verify the conversion and when galleys are generated. The software reduces handover steps, but it does not determine whether an affiliation is correct or whether a table is understandable when read on a phone. Those reviews remain an editorial responsibility.

What a specialized service can carry out

A specialized service can receive the already approved article and carry out defined tasks: normalize the input, structure the content, prepare PDF, HTML and JATS XML, apply a template, check consistency between outputs and return a proof for approval. Jatson describes that path from the accepted article to the publication assets and mentions a review before delivery.[4][5]

The division works best when the brief specifies inputs and outputs. Define which document is delivered, what happens with poor images or tables, how many rounds of comments the workflow allows, who validates the XML and how the final version is named. Without those rules, the service may receive queries that still belong to the editorial decision and the closing becomes confusing.

According to OJS ONE's practice, manual tagging can take about 4 hours per article; with automation, minutes. That reference helps size repetitive tasks, not promise a fixed deadline: the result depends on the state of the document, tables, figures, references and pending corrections.[3]

Mistakes to avoid when combining both routes

The first mistake is assuming that generating a file is the same as approving it. An XML can be structurally valid and still contain an affiliation, a reference or a caption that needs editorial correction. Separate technical validation, reading review and content approval.

The second is keeping two competing sources. If one correction is made in OJS and another in the external XML, agree on which file governs the next update. PKP warns that, in the scenario described for OJS 3.6, JATS metadata and the OJS database are not yet linked to reflect changes in both directions.[2]

The third is requesting an output without delivering a closed input. A document with irregular styles, incomplete references or pending figures moves the problem to the end. Do an editorial pre-review before producing and record the comments that the journal must resolve.

The fourth is measuring only the visible cost. Compare hours of preparation, queries, corrections, file coordination and proof review. This comparison does not decide on its own; it provides a basis for selecting a route the team can sustain.

A five-step adoption plan

Start with one representative article, not with a broad promise. The goal is to check responsibilities and output evidence.

1. Define the sample. Choose an article with references, a table, a figure and the usual elements of your journal.
2. Fix the source. Define whether OJS HTML or the external JATS will be the reference for a later correction.
3. Assign owners. Name who prepares the input, who resolves queries and who approves each format.
4. Compare proofs. Review PDF, HTML and XML against the approved manuscript and note differences.
5. Adjust the workflow. Document internal deadlines, checkpoints and conditions for repeating the process.

This pilot lets you adopt integrated production, external execution or a mixed scheme with a decision based on the journal's own evidence.

Frequently asked questions

Does OJS 3.6 remove the need for a production service?

No. OJS 3.6 incorporates an integrated route for HTML, PDF and JATS XML, but PKP keeps traditional workflows and third-party services available.[1] The need for outside support depends on internal capacity, design, the complexity of the articles and the closing control your team can take on.

What should the journal hand over to a specialized service?

The basis is an approved article, confirmed metadata, figures, tables, references and a definition of the required formats. Before sending the material, it is wise to agree on the template, approval owners and handling of corrections. Jatson describes its input as the source content of the accepted article.[5]

Does automation replace editorial review?

No. Automation can reduce repetitive work and generate outputs from a common source, but the journal must validate content, metadata and the readability of each proof. PKP notes that certain complex or atypical styles may require extra attention during the transformation.[2]

Evaluate Jatson for your journal's production

OJS 3.6 opens an integrated option for organizing multi-format production. A specialized service can complement that option when you need to concentrate execution, checks or defined assets. A convenient combination leaves a clear source, identified owners and a verifiable editorial approval.

If you want to evaluate a production route for JATS XML, editorial PDF and reading HTML, see the scope of Jatson. You can set it against your OJS 3.6 workflow and request an evaluation based on a reference article.

Sources

1. Public Knowledge Project, OJS 3.6: Bringing Manuscript Editing and Production under one Roof — accessed 2026-10-23.
2. Public Knowledge Project, Upload, Transform, Publish: Inside OJS 3.6’s File Production and Toolset — accessed 2026-10-23.
3. OJS ONE, Editorial production automation — accessed 2026-10-23.
4. OJS ONE, Editorial production for OJS journals | OJS One Jatson — accessed 2026-10-23.
5. OJS ONE, JATS XML Tagging for SciELO Chile | OJS ONE — accessed 2026-10-23.