One of my research sources (Oxford Review) creates PDFs that are marked readonly only. They don’t understand why this happens. Rather than debug their authoring process I would like to create a smart-rule that finds readonly pdfs when they arrive in the inbox and duplicates them as writable.
Is this possible? I can’t find anything in the matching rules for ReadOnly PDFs.
If it helps I could do this with AppleScript or using Hazel.
There is no criteria for a read-only state nor is there an action or AppleScript command to change this specific state.
You could try Data > Convert > To Paginated PDF.
Is there an Automator or AppleScript I could run to copy the file and strip the readonly attribute buried inside the PDF? I ask because I already have Hazel moving these files to the inbox. I know the Preview app is capable of making a writable copy, because that is how I currently work around the problem in a fully manual fashion.
What exactly are you doing in Preview to modify this?
PS: Whoever is generating the PDFs should be looking for a resolution to this issue.
PPS: Select a PDF in the Finder, compress it, and attach it to a new support ticket.
I asked the OR and they don’t know what is creating the problem, now I wonder if it is a DT problem. I export the file from DT to a new folder it is editable. However inside DT it isn’t. This also happened when I downloaded: (PDF) Tell Me What I Did Wrong: Experts Seek and Respond to Negative Feedback (JCR) | Ayelet Fishbach and Stacey Finkelstein - Academia.edu and imported the Document into DT. Its marked Readonly. Where as when it’s on the filesystem it’s editable.
Editable via… what?
When the files are still sitting in my downloads folder I can edit them. When they’re moved to the inbox in DT they’re become uneditable. (BTW Isn’t it night time for you?)
Actually, I do keep weird hours but I’m in the US. 
Are you referring to not being able to annotate a PDF in the Global Inbox as being “uneditable”?
Somehow I assumed all of the DT was in Germany. Now I know 
yes. Hopefully this ScreenShot shows the problem:
This might be an automatic protection to prevent possible issues after editing the document due to PDFkit bugs. The next release will include a hidden preference to disable this. In the meantime one workaround is to convert the document to a new paginated PDF (via Data > Convert).
I will wait for the next release. However your comment says: “after editing”. Except the lock symbol in DT is present before I try to annotate/highlight.
Exactly as editing might cause the issues.
I am wondering if this has been resolved and that there is now a command to take PDFs out of read-only mode. I have some PDFs created by an archive authority where I am not able to edit the PDF properties, which are all blank at the moment. In DT the preview window shows the read-only icon (barred pencil) and I am not able to edit. However, if I open this document externally in PDF Expert I can edit and modify everything and when I save it, the new edited information shows up in DT’s Inspector panel, but in the DT preview the read-only icon is still there. For some reason DT flags some PDFs as read-only while they are not.
Take a look at the “DEVONthink Manual”, 3.9.6 version, page 255. The hidden preference “ForceEditablePDFs” might be what you are looking at and that @cgrunenberg hinted at above 2 years ago about a then “next release”. If not that hidden preferences, look through the others.
Many thanks for your help! That did it, now I can edit. Great!
By the way, there is not an inherent issue in DEVONthink. Some PDFs have fonts incompatible with Apple’s PDFKit, an issue that has the potential to corrupt the text layer of a PDF. Hence, DEVONthink marked them as read-only. Recent changes we’ve made should help mitigate that but there’s no guaranteed fix without Apple fixing PDFKit. Also, PDF Expert does not use PDFKit, which is why you didn’t see an issue there.
Many thanks for the clarification. I am probably dreaming, but let us hope that Apple soon will spend some time on the PDFKit. PDFs are such an important part of document handling that I feel they should invest some efforts here.
You’re welcome! And indeed, that would be ideal but we’ve been waiting for them to fix PDFKit for years now. As Apple has moved away from focusing on the professional market, things like this have fallen by the wayside in favor of making more shiny things instead. 
Why would they fix PDFKit at all? They’ll simply train their AI to fix the PDFs. Or tell us to use Pages instead of PDF 
Haha! Sadly, there may be a bit more truth than I’d like to admit in that riposte 
