@felwert @stefanmuelller @glossa @PublicKnowledgeProject

But back to my original point -- editors want published articles to look good, and "print to PDF" doesn't get them all the way there (though it does support a lot of publishing)! The gap can't entirely be met with technology.

However, we are getting a little less agnostic about how typesetting happens in OJS. Watch for some first steps in OJS 3.5 and beyond.

@felwert @stefanmuelller @glossa @PublicKnowledgeProject

Lately we have been talking about integrating an HTML editor into OJS, using a limited vocabulary that can be mapped back and forth to JATS. This would allow us to use existing off-the-shelf tools without giving up the ability to interoperate with the scholarly ecosystem that uses JATS, and without waiting for a sustainable FOSS JATS editor to spring to life.

@felwert @stefanmuelller @glossa @PublicKnowledgeProject

Unfortunately several of the key free/open source JATS tools we pinned our roadmap to over the years died on the vine: Texture, Lens Reader, and Libero Editor. I think this reflects the extremely broad nature of JATS, and the resulting difficulty in coding/maintaining a tool to work with it comprehensively without picking a limited sub-vocabulary.

@felwert @stefanmuelller @glossa @PublicKnowledgeProject

Typesetting in OJS is a big subject for PKP, and is often (but not necessarily) tied to the subject of JATS tooling. My opinion: JATS is an amazing standard (and we will continue to push better integration into OJS) but will not make typesetting pain-free. Templates will still be needed to convert to PDF/HTML and creating/maintaining those is expert work. Many publishers have been told "JATS solves typesetting" and don't expect this.