After a lot of work on all sides (we did a contentual and graphical redesign and in parallel went a long rocky road with the first installation and setup of OJS3) we’re finally done with our brand new issue 26/1–2 (2017) of the OpenAccess journal »TATuP – Zeitschrift für Technikfolgenabschätzung in Theorie und Praxis«, which is freely available in print and online: http://www.tatup.de/
(It’s mainly in German, but a few articles are in English.)
Thank you very much for all the support, that helped us to stay on the right track. This forum is awesome! Thanks to all kind helpers and many special thanks to the development team of PKP/OJS, which is extremely helpful, communicative, and usually blazing fast in answering or killing small bugs!
Thanks in the name of my whole team!
Karlsruher Institut für Technologie (KIT), Karlsruhe,
Institut für Technikfolgenabschätzung und Systemanalyse (ITAS), Karlsruhe,
oekom Verlag, München,
and me, Tobias Wantzen
@kawahyu, this is up to now still work in progress. We did the layout and final corrections in InDesign, exported the print and web PDFs, and finally exported HTML5 directly from InDesign. This export went through some automatic and manual steps of cleaning and restructuring.
I’m still not fully satisfied with (a) the code result and (b) the process itself. There is still much room for improvement
We do plan to get over to JATS XML, but for now it was quite a big amount of work to bring everything up to this point. We’ll expand step by step …
Thanks for the response @Vitaliy
With your tool, I wish I can create xml files with APA citation.
or manually edit the produced xml by your tool for APA reference format if the first work requires further difficult work
We are publishing a journal which is (mainly) written in German. So after testing OpenTypesettingStack (OTS) and DOCX2JATS and http://www.tei-c.org/oxgarage/ – which are all great tools! – there are 2 points, that come to my mind on this topic: 1.
All projects that try to convert DOCX (or another format) to JATS/NLM XML base on English and/or the native language of the programmer. IMHO all developers don’t lay enough attention on the requirements of other languages for their piece of software. There should be basic support for localization with config files, which allows something like this:
[recognizing page references] EN: p. // DE: S. // […]
[grep for bibliographic references] [\d+]
This could possibly allow a relevant increase of positive results of XML output. 2.
I can see, that everyone tries to analyze and resolve the myriads of DOCX formatting possibilities. But why does noone try to setup a »standard« way and optimize his tool to this? What I’m trying to say: Why don’t we try to evolve a Word/OpenOffice/LibreOffice template file and define how the predefined style sheets has to be used (user guide). When someone uses this template file and does a clean formatting, that follow the rules documented in the user guide, the XML file could be much more precise.
This will open another positive aspect: We could use this Word/OpenOffice/LibreOffice template to send it to the authors.
And all 3 programs are based on one main mechanism Most of the parsing work is done via the same XSLT.
I already know how to make mostly ideal converter. There are good tools in Java for that. But it requires time that I don’t have for now.
For example there is a library that allows in few simple lines of code to get the data from all DOCX archive (it contains several files in OOXML format). If the references are made with Word tools or Zotero Plugin they would be ideally parsed into JATS XML. Tables can be ideally converted. Meta-data from the Word’s document properties (article title, authors, affiliations - if they explicitly pointed in Word document) can be easily retrieved, etc.
Hi @kawahyu,
it’s a child of the standard OJS3 theme. The block you cited above is the »Additional Content« text. You could find it at »settings > website > appearance« near the end of the page.
I hope it helps.
Thanks
Tobias