To see the executable flag you must share the file with a link that gives access to everybody. I have attached a screenshot to this message.
Here is the link to my Google Drive: sample.pdf - Google Drive - it seems to still be OK.
EDIT: Ah, so the warning happens when you download it.
Interesting; this happens with PDFs generated using LO 3.3.
It would be nice to ask Google why do they issue this warning. It may be something wrong with our files; but just as well, it could be some problem on their side.
Thanks for the advice. I have generated a pdf with PDF/A ISO 19005 format and the problem persists. I have tried the three PDF/A versions (1b, 2b, 3b). Here is a file with PDF/A-2b format.
pdf A.pdf (23.7 KB)
In the export-as-pdf dialogue there are some marked boxes that I can’t unmark. Probably one of these options is causing the problem. I see “Tagged PDF (add document structure)” in the General tab and the following:
Exactly! Google is the one to blame because other storing services don’t see any problem with the files I create with LibreOffice. Or maybe Google knows something that the rest don’t. One day we may know what Google knows and why they do what they do.
I have posted this problem in the Community Support of Google but still no good answer. I’ll create a post in English because the Spanish Community is not very active.
Thanks; and I posted a support request from my GDrive. I hope they would get back to me with some clarifications.
1 Like
Yes, I use the Web UI to upload the pdfs.
I’m using Manjaro. It’s fully updated. About LibreOffice I have the 7.4.6.2 community version.
Yesterday I created a pdf on Debian and Google Drive also tagged the pdf as executable. I’ll try to create a pdf from a Windows machine at work to see if the problem replicates also there.
I also think that changing some attribute in the pdfs created in LibreOffice could do the trick, but I don’t think we can apply a workaround as mere users.
Could you replicate my problem to discard that if it happens only to me? Please, follow these steps:
-
Create a pdf in LibreOffice using the export-to-pdf button in the toolbar.
-
Upload the pdf to Google Drive.
-
Get a link to share so that everybody with the link can see it and download it.
-
Open a private window in your browser, paste the link and try to download the file.
If the file downloads straight away not showing this warning message, then the problem is probably my computer or the distros I use:
Read above: @mikekaganski and @mariosv get the same note as you.
.
Funny note: My Android-phone opens the Link of Mike without any warning, so Google seem to warn only desktop users, or only, if there is space on the screen…
.
But re-reading your question. You don’t have any pdf in your Gdrive, wich is not flagged executable? So ALL pdfs are tagged?
Here is an example of pdf that is not flagged. I have just created it in LibreOffice with a pdf printer: https://drive.google.com/file/d/1tOrvV6YzvNQcD5xeZg_j0MLy5fumllnT/view?usp=share_link
I love GNU/Linux! I have been trying to know what is wrong with the pdfs and finally I found the solution. Sadly, there is nothing I can do and I think that only the programmers of LibreOffice can solve the problem.
.
I have followed a tutorial on using a program called peepdf to disect pdfs. I have compared the outputs of an ok pdf and a executable pdf.
.
Here is the output of the ok pdf:
.
.
Here is the output of the executable pdf:
.
.
The difference is in object 12. Let’s see what object 12 is made of:
.
.
Voila! There it is. A simple string that says
/OpenAction [ 1 0 R /XYZ null null 0 ]
is the one to blame. I have found this Github issue from the mpdf project that clarifies how to solve the problem: https://github.com/mpdf/mpdf/issues/602
.
Now it’s only a matter of some small code writing to repair the export-to-pdf extension in LibreOffice. I don’t even know how to report this issue to the development team in LibreOffice as I am not a programmer myself. Is anybody here in the development team? Can anybody open a ticket about this topic?
3 Likes
Anyone can report bugs, it is best for accuracy if the person encountering the bug does it, How to Report Bugs in LibreOffice - The Document Foundation Wiki
You are right. I am working on it. But I have found a problem when reporting the bug: I have to specify the earliest version of LibreOffice with the bug. All this is too new for me and it would take me some time to learn where to find older versions of LibreOffice, how to install them for testing and reproducing the bug in every version. Anyway, I will do it but it will take some time.
Please do not consider the stuff there as some “requirement”. It’s not to force you to investigate: it’s just which oldest version do you know. I.e., if if didn’t work for you in prior 7.5.2, and now you installed 7.5.3, and it still doesn’t, you don’t put the latest 7.5.3, but the 7.5.2 (even if later someone discovers that it didn’t work in 4.4.)
Don’t waste your time at all. Just put there what you already know, and don’t feel like you need to spend even more time.
@Eugenioh please do not forget to mention the bug number here; it would allow others to see its progress; and I’d be able to add some data there, and confirm it. Thanks!
Thanks for the advice about reporting the bug. This is the link to the bug number https://bugs.documentfoundation.org/show_bug.cgi?id=155419
.
After submitting it I saw some mistakes in the bug report, but it’s impossible to edit it in Bugzilla 
. I hope the content of the report is understandable enough.
1 Like
Based on the brilliant analysis by @Eugenioh in post #21, here is a workaround - until the bug is filed and fixed (making the default case with the first page displayed with default magnification to not write the action):
When exporting, set the Open on page to any value greater than the number of pages:
This is because the current code skips writing the /OpenAction when the page happened to be out of range.
3 Likes
Indeed, Google, but I believe the problem has to do with temporary files.
If you are editing an existing document stored on Google drive, Libre and many apps, copy the document to a temporary file, often giving it a file extension of ‘.tmp’.
From Google Drive perspective, this is a NEW file. At this point, Google is deciding it’s a binary. In Google Drive, once created, it’s impossible to remove the ‘binary’ attribute. When you save the file, Libre renames the file with the appropriate file extension and the original filename, but it’s too late to remove the binary attribute.
I am having same problem with todotxt-cli (Debian package), when doing edits to it’s txt file to Google Drive via GDFUSE from Debian.
Unrelated. The problem is with PDFs pre-created locally, and then copied to GDrive using Web interface. No editing takes place during the test. Freshly uploaded PDFs that were originally generated by LibreOffice have this problem. PDFs uploaded the same way, but coming from different generators don’t.
I support your idea because not all the pdfs I upload to Google Drive are tagged. Here is an example of a pdf I have created in LibreOffice but instead of using the export-to-pdf button, I have used a pdf printer. This file isn’t tagged at all: https://drive.google.com/file/d/1tOrvV6YzvNQcD5xeZg_j0MLy5fumllnT/view?usp=share_link