Further I have problems with adding Swedish language files for oldgregg. It used to be only to add a folder sv_SE and a locale.xml into that. But it does not work on the current version
I don’t see a pull request, or you are keeping those locally?
This looks like an error from the JATS Parser Plugin related to the recent changes in OJS regarding publications versioning. It will be fixed in the next release.
The old way how JATS XML galley page was rendered has changed. Now, the new upload full-text tab appears in the Publication’s menu, which allows extracting full-text from JATS XML file, uploaded on the copyediting or production stages. This text appears under the abstract on the article landing page after submission being published. I’m removing rendering of XML galley page by the plugin completely, as it’s redundant.
We are about to update to 3.2, but the journals using OldGregg has serious problems due to this. In what timeframe do you plan to have the new version ready?
Old Gregg theme is compatible with OJS 3.2 so I don’t think there will be a new release before OJS 3.3 is out. As for JATS Parser Plugin, the new release is coming soon. I’d expect it in mid December. If you are interested making a fix, the line that causing a problem is here: JATSParserPlugin/articleGalleyView.tpl at adeac5844a9e25654b516e943ff166fa24babc3c · Vitaliy-1/JATSParserPlugin · GitHub In OJS 3.2.1 Some part of submission’s logic was transferred to a Publication object, leading some Submission’s methods, like this one, being deprecated or removed.
Yes, it’s removed from the master branch of the JATS Parser Plugin. I’ll re-add those before the release; PDF will be generated statically, the option will appear under the Publication tab.
Cannot reproduce this, e.g.: https://uk.e-medjournal.com/index.php/psp/article/view/242
How this full-text was generated? Can you re-check whether the original JATS XML file contains the attached images with correspondent file name?
In Texture I tried to add an image “Figur1.jpg” and one “Figur 1.jpg”. Both are shown in Texture, but only the one without space is shown in the published version. Do I need to reupload all figures now?
Another question:
Since you are not using galleys anymore for publication. Then should we remove the XML galley? It is not needed anymore, right!?
Is it possible to also choose an XML-galley in the tab “full-text upload”? I mean if the editor has uploaded a edited xml file as an galley then the production ready files will not be the same version as the XML-galley.
In the JATS Parser Plugin settings (master branch, see plugins tab), there is an option to convert all JATS XML galleys to the article’s full-text at once (Import full-text from galleys). It can help to reduce the amount of manual work. I suggest waiting until the official release, which is planned soon, and then convert galleys but if you have a possibility I would appreciate some testing.
The full-text now is actually a publication property, this means it’s handled in a similar way as abstracts and other publication data. In other ways, JATS Parser Plugin won’t interact with XML galleys. If JATS XML galleys are already there, I suggest not to delete them but leave them as is as it’s a part of an already published publication.
If keeping XML galley the same as a full-text and new XML galley is uploaded, then full-text should be re-generated.
Once again, the idea is to treat a full-text as a Publication’s property, like other data, going away from the concept that it should be displayed as a galley.
According to JATS XML standards the value of the xlink:xref attribute should be a valid URI. Figur 1.jpg isn’t a valid URI, so I’d discourage such usage. But if Texture allows this, I guess, there is room for a workaround. @eddoff, can you check if changing this line:
Just merged into the master branch yesterday. The checkbox to create a PDF galleys is under the Full Text tab of the Publication. But the release itself is planned short after OJS 3.3. There are other issues that I want to solve plus in 3.2 it’s possible to hit this issue if article’s full-text is long.
I think you can install dependencies locally and then create a tar.gz archive to upload to OJS. If you have problems with installing composer locally, let me know, I don’t mind creating a second beta release for testing.