Remote PDF's to local

Hi,
This is a longshot, but for ojs 3.1, is there a way to convert from a remote pdf to a local pdf other then using the import/export tool?

We ran into a problem where the content-type for JATS xml would not be ‘application/pdf’. Looking in the database I don’t think remote files are able to have that value. I made a quick hack by hardcoding in the content-type but that’s not ideal.

Reason I ask is I would like to keep the original submission ID’s of the remote files. There are a lot of them so manual upload is not really possible.

Jeremy

Hi @jhennig,

I can’t think of an easy way to convert remote galleys to local – but can you describe the underlying problem a little more? I’m not sure I’m following.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

If you look at this xml:
https://iassistquarterly.com/index.php/iassist/oai?verb=ListRecords&metadataPrefix=jats&from=2020-04-01

Look at this line:

The pdf it’s referring to is a remote file. The content-type was blank before I hacked in a fix. Without that value the journal’s harvester doesn’t know how to download the file.

I modified this file: https://github.com/pkp/oaiJats/blob/master/OAIMetadataFormat_JATS.inc.php

at the _mungeMetadata function to say:

			$contentType = $galley->getFileType();
		
		if($contentType == ""){
			$contentType = 'application/pdf';
		}
		$uriNode->setAttribute('content-type', $contentType);

Hi @jhennig,

Ah, I think we actually shouldn’t be providing a content-type at all in that case. That’s an optional attribute; do you know if the harvester you’re working with is able to determine content types when they aren’t specified? (It’s possible that the attribute being present but without a value is interfering.)

Regards,
Alec Smecher
Public Knowledge Project Team

I see. I don’t know anything about the harvester. The end user’s are working with it. I’ll let them know.

Thanks
Jeremy