Upload, Transform, Publish: Inside OJS 3.6's File Production and Toolset

Feature image for the article. The text is the same as the article title. The photo on the right half is a yellow and black butterfly fluttering about, feeding on pollen rich, small pink flowers. The butterfly represents first the upload in OJS 3.6 or the larvae, then the transformation or the cocoon where the creature changes, and then the publishing or the emerging of the full butterfly. — Design by PKP’s Famira Racy. The butterfly represents first the upload or the larvae, then the transformation or the cocoon where the creature changes, and then the publishing or the emerging of the full butterfly.

A closer look at the new OJS 3.6 features and tools that turn a submission file into on-demand JATS, HTML, and PDF galley files.

The previous article, OJS 3.6: Bringing Manuscript Editing and Production Under One Roof, introduced the SciFlow integrated text editor and the concept of file production from a single HTML source.

This article looks at the tools associated with the file production process, the supported workflows, and the community priorities that are shaping future production capabilities in OJS 3.6. The first release of this version is scheduled for Fall 2026.

Transforming the Submission into Editable HTML and Structured Metadata

Let’s look at a typical OJS workflow through the lens of OJS 3.6, starting with a Word DOCX upload. If enabled, the GROBID plugin auto-extracts metadata from the submission and stores it in OJS. If Structured Citations are enabled, Crossref and OpenAlex are used to look up DOIs and ORCID identifiers.

Regardless of how metadata makes its way to OJS — via auto-extraction or manual entry and subsequent curation by the editor — the important point is that the submission process results in the extraction of metadata from the DOCX file:

DOCX Submission to OJS → DOCX + Semantic metadata

Once the submission is assigned to an editor, it undergoes the journal’s submission-stage checks before the peer review process kicks off. At the copyediting stage, copyeditors can edit the body text content using the ‘send to text editor’ menu option. This triggers Pandoc*, a free and open-source universal document converter, to transform the DOCX body text to HTML which is then imported into OJS’s text editor.

Invoking the text editor transforms the body text portion of the DOCX file to HTML:

DOCX (body text) → HTML + Semantic metadata (saved to OJS)

Note that the text editor displays metadata such as references in its sidebar for easy drag-and-drop editing to the main text.

Pandoc runs in the browser and, due to its small file size, will not slow down OJS. During this transformation process, individual images are extracted and saved. Table and formula layouts are preserved. Complex or atypical styling may not be transformed perfectly, but will improve as the SciFlow editor continues to make improvements.

OJS 3.6 takes the submission file and performs a transformation to create editable body text HTML and structured (machine-readable) metadata. The results of this transformation are what enable file generation inside of OJS.

HTML, JATS and PDF File Generation

To produce an HTML galley file, the standard workflow remains available, in which the journal’s logo, title, and overall styles are applied to the body text. The resulting galley HTML file can appear inline on the reader-facing side and as a standalone, downloadable file. Edits made with the OJS text editor allow on-demand HTML galley file generation.

In OJS 3.5, once the JATS content is generated from the submission or externally produced and uploaded, it is not updated, regardless of content or metadata changes. In OJS 3.6, the file transformation process from DOCX to HTML generates JATS-friendly HTML, making the HTML to JATS mapping — and update — a trivial exercise. As is the case with the standalone HTML and PDF files, JATS XML files can optionally be available for download.

One of the most exciting features of OJS 3.6 is the ability to produce accessible and styled PDF outputs without using the standard print to PDF from Word, which often results in poor layouts. Using HTML produced in the transformation process as its input, printCSS applies the stylesheet and Vivliostyle*, a third-party open-source tool, renders the result into a PDF, using printCSS directives to apply pagination, column layout, and more.

By establishing HTML as the canonical source for file production, the key benefits include:

Galley files can be produced on-demand as changes to body text or metadata are made
The ability to consistently produce semantically structured HTML with proper heading hierarchy, ALT text for figures, and tables that can be navigated via keyboard
PDFs can inherit an accessibility-friendly structure from HTML rather than needing to create it from scratch

Three Workflow Scenarios

The standard workflow is still available: once a submission is uploaded, it undergoes the basic checks before starting peer review. After peer review acceptance, the manuscript undergoes copyediting which leads to PDF generation and publication. Optionally, the text editor can be used in this workflow for HTML and PDF file generation.

The second workflow is the Publish, Review, Curate (PRC) model which is used in Open Research Europe (soon to be an OJS 3.6 based platform). In this model, once a submission passes the pre-publication checklist requirements, typesetting is applied to the preprint. PDF, HTML, and JATS XML are then produced and made available on the public site. Outside of Open Research Europe, the more common workflow is a hybrid model where the PDF preprint is published without typesetting and after peer review acceptance, the final version of record is typeset and transformed into HTML and PDF galley files.

A third workflow is JATS-centric, but it has never been included in OJS and is not included in OJS 3.6. This workflow involves external services that produce JATS from DOCX when the submission is accepted. In this process, JATS is the source document used to produce the HTML and PDF galley files.

The Outlook for Metadata Roundtripping in OJS

Currently, the JATS metadata and the OJS database are not linked, meaning that updates in OJS will not be reflected in JATS. However, there is an increasing demand for OJS to be able to accept enriched JATS metadata. For example, Coalition Publica, the Canadian national platform that partners PKP and Érudit, produces such enriched metadata and downstream services including Crossref that would benefit from these updates. While the demand has been identified, the solution has yet to be determined.

* The OJS 3.6 production tools, Pandoc and Vivliostyle, are flexible, lightweight, require no additional hosting, and work with multiple file formats. These updates reduce or eliminate external dependencies while keeping existing workflows available. For journals currently relying on external services, this represents a path to bring production in-house without changing existing processes.

Check out the May 2026 PKP Development News Update Webinar for more information on PKP’s recent OJS / OMP / OPS software developments.