Description: When exporting PDF files with forms that have option buttons (radio buttons) in LibreOffice 6.3, the resulting PDF file has issues in Acrobat Reader / the PDF reader in Microsoft Edge. The problem is that radio buttons cannot be selected (checked). In Linux, using Okular, they work fine. When exporting the same .odt file as PDF form in LibreOffice 6.2.6, the form works correctly in Adobe Reader / Edge - the radio buttons work as expected. Steps to Reproduce: 1. Create a new document in Writer. 2. Add some option buttons. 3. Export as PDF (enable "Create PDF form"). 4. Open the file in Adobe Reader / Edge. Actual Results: The option (radio) buttons cannot be checked (marked as selected). Expected Results: The option buttons should be selectable, as they are in the PDF files exported in LibreOffice 6.2. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.4 Build ID: 6.3.0-0 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: kde5; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Also replicable in LibreOffice 6.3.0 in Windows 10.
I tested with master 6.4+ in Windows and exported PDF form can be checked in PDF-Xchange and Foxit (reporter already said Okular in Linux is fine) but cannot be checked in Adobe Reader XI. This may be the bug or NorOurBug. So I add NeedsDevAdvice. Until then, I'll set to New. Reporter, please write your Adobe version and test with older and newer. You marked as Linux but I'd say this is not OS issue, rather PDF reader. Although the issue is not related, see differences in PDF readers in Bug 84963.
Created attachment 153749 [details] Test ODT Reporter had better attached a sample. I'm doing it now.
Created attachment 153784 [details] tail of terminal output from bibisect in 64-6.3 repo evince 3.30.2, as delivered with debian-buster shows the difference between clickable radio buttons from older LO vs. not-clickable buttons from recent LO. Of course, this does not prove that the bug is ours. I do not understand the pdf format well enough to have an opinion. Working in the bibisect-linux-64-6.3 repository, I find: commit s-h date -------- -------- ------------------- good 9c6a30c7 1e8a9c19 2019-07-03 12:45:35 bad 998e100d 76b5dca9 2019-07-03 12:45:45 From git log: commit 76b5dca9dc0ff60f8f62cbecdee68f8f3b287ceb Author: Thorsten Behrens <Thorsten.Behrens@CIB.de> Date: Tue Apr 9 02:19:14 2019 +0200 tdf#113448 don't export any font for radio buttons Change-Id: Ie84b19a3dfaec32184bb825b7593ec33a5c4145c Reviewed-on: https://gerrit.libreoffice.org/74994 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 6ec26ba3aa195eac62fb8803137070d23a69491c) Reviewed-on: https://gerrit.libreoffice.org/75012 Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de> I am removing bibisectRequest and adding bisected.
*** Bug 127917 has been marked as a duplicate of this bug. ***
*** Bug 128020 has been marked as a duplicate of this bug. ***
OK @Oliver Brinzing
*** Bug 128664 has been marked as a duplicate of this bug. ***
*** Bug 128822 has been marked as a duplicate of this bug. ***
Created attachment 158164 [details] Invoer.odt - testcase Another testcase. Output in LO 6.4.0 works with: * Foxit PDF reader * Google Chrome * PDF Reader by Xodo works not with: * Adobe PDF Reader DC * Microsoft Edge
Created attachment 158165 [details] The PDF generated with LO 6.4.0
Created attachment 158169 [details] The PDF generated with LO 6.2.8 Works with: * Adobe PDF Reader DC * Google Chrome * Foxit PDF Reader * Xodo PDF Reader Doesn's work with: * Microsoft EDGE
Here, the behaviour of Microsoft EDGE is different. With LO 6.4.0.3, it won't check the radiobuttons. With LO 6.2.8, it will check all radiobutton (as if they were checkboxes).
*** Bug 130891 has been marked as a duplicate of this bug. ***
*** Bug 131690 has been marked as a duplicate of this bug. ***
Is it planned to fix this defect within one of the next releases in the near future?
I think I've found a trick to solve this problem that may help the LibreOffice developers to get rid of this bug. First, I would like to point out that I am using the latest version of LibreOffice 6.4.5 and I confirm that this bug exists on all platforms I use (OSX Mojave, Windows 10, Ubuntu 20). 1- On Mac OSX Mojave, I created an .odt file with two buttons (see attached file: Test_buttons_LibreOffice_6.4.5.odt). 2- Then, I exported this file in fdf format (see attached pdf file: Test_buttons_LibreOffice_6.4.5_Before.pdf). 3- I made a copy of this pdf file and renamed it (see attached pdf file: Test_buttons_LibreOffice_6.4.5_After.pdf). 4- Then, I opened this last file (Test_buttons_LibreOffice_6.4.5_After.pdf) with the "Preview" application and saved it with a Cmd+S. The results are then the following: With the "Preview" application, the two files "Test_buttons_LibreOffice_6.4.5_Before.pdf" and "Test_buttons_LibreOffice_6.4.5_After.pdf" work fine (the buttons are selectable and the selection of one is incompatible with the selection of the other). But, the "Test_buttons_LibreOffice_6.4.5_Before.pdf" file does not work with "Adobe Acrobat Reader DC", while "Test_buttons_LibreOffice_6.4.5_Before.pdf" works perfectly . In other words, the "Preview" application has added data in the "Test_buttons_LibreOffice_6.4.5_After.pdf" file that do not exist in the "Test_buttons_LibreOffice_6.4.5_Before.pdf" file. I think then developers will be able to find this added data and see the origin of the bug.
Created attachment 162743 [details] Two radio buttons in odt file
Created attachment 162744 [details] Two radio buttons in pdf file before changes made by the "Preview" app.
Created attachment 162745 [details] Two radio buttons in pdf file after changes made by the "Preview" app.
Same problem here. LO Writer Version: 6.4.5.2 Build ID: 6.4.5.2-2.fc32 Evince Document Viewer 3.36.7 fails Xreader 2.6.4-1 fails Okular with "show forms" works! With evince, I can just barely see a difference when the control is clicked on. Its as if the dot has no color (transparent?) but then displays only a very faint shadow for the dot. I can also verify that the Before/After pdf's that were posted works as promised using evince. The 'Before' pdf fails and the 'After' pdf works just fine. I'm not sure what "preview" app we are talking about here, but it does seem to fix the problem. I tried diffing the documents but need better tools to decode the pdf's.
I see this defect is assigned already - will it be fixed soon? I would like to upgrade to version 7 - but the problem still exists within this version.
*** Bug 134813 has been marked as a duplicate of this bug. ***
*** Bug 136849 has been marked as a duplicate of this bug. ***
Xisco, please see to revert this commit. Fix is worse for more users than original issue, which can be reopen with normal priority.
This is the last chance for fix in LO 6.4.7.
(In reply to Timur from comment #26) > This is the last chance for fix in LO 6.4.7. 6.4.7 ? I'm using 7.0.1.2 already ???
I opened my pdf file ( Bug 138649 ) in Nuance Power PDF Advanced. When I set in to Form, and click on the properties of what should be one of my radio buttons, Power PDF thinks it is a Check Box, not a Radio Button. That could explain a few things.
I did some more testing,and when I use an option button and a check box in an Writer document, both turn op as a check box in the forms editor of Power PDF. So I'm quite sure there is a problem in the forms editor of Writer, or in the export to pdf.
Some more thoughts on this matter. Let's assume this is an error in Writer, as it appears to be. Older versions of Adobe Acrobat, as well as other pdf readers handled the erroneous pdf instructions as if there was no error. The present version of Adobe Acrobat can be more strict, and refuse to handle the error this way. This is not uncommon, I have seen this many times in compilers etc. Source code that was accepted in one version of a compiler, was refused in a newer version. You had to do a bit of thinking to find out what was wrong, but usually the new compiler was right in refusing the source code. Browsers had the same problem. The infamous Internet Explorer accepted al kind of HTML junk that other browsers could not handle.
(In reply to Dirk Munk from comment #30) > Some more thoughts on this matter. > > Let's assume this is an error in Writer, as it appears to be. Not to discourage participation, but if I'm reading the earlier comments right, I think they already found the change in LO that broke it. (See #3.) Something about assigning / not assigning fonts to form widgets in PDF generation: https://git.libreoffice.org/core/+/76b5dca9dc0ff60f8f62cbecdee68f8f3b287ceb%5E%21 . That commit might be what comment #25 is referring to.
Is there any chance to get this issue solved ? I'm running LO 7.0.1 both on Linux & Windows, with the same consequence on radio buttons within a PDF created file. Those buttons cannot be selected, or, may be, displayed as selected in the reader (black circle not visible). Note: I programmatically edited the PDF file (via pdftk + FDF data), and there, when I set radio button to selected in my FDF data, the PDF file generated is displaying radio buttons status properly. This means the PDF file has the appropriate information within, but may be something is blocking PDF-readers (Adobe acroread,...) to properly behave... Thanks in advance to anyone who could bring a solution there...
*** Bug 137554 has been marked as a duplicate of this bug. ***
On LO 7.0.3.1, it's worked
(In reply to rolland.julien.29 from comment #34) > On LO 7.0.3.1, it's worked I'm sorry for these comment. From LO 7.0.3.1, radio buttons from PDF exported can read from browser (MozDev 83.0b7 (64-bit) | Chrome 86.0.4240.111 | Edge 86.0.622.51 | Opera 72.0.3815.186 on Windows 10) but not from Adobe Reader DC 2020.012.20048 (Windows 10 x64). It seems that PDF exported have an other element within radio button which hide it.
I compared some PDFs in MasterPDF, which I exported with earlier versions of writer with others, I exported with the actual Version (6.4..). The difference is, the widgets themself (not the Text - the circle-widget) in earlier versions have fonts (ZaDi or ZapfDinbat) while the widgets in PDFs from LO 6.4.x have none. The widgets of checkbuttons have even in PDFs exported from the actual writer a font (named F7) and so they work.
*** Bug 138132 has been marked as a duplicate of this bug. ***
I could reproduce the problem with LO 7.0.3.1, default ubuntu document viewer or acrobat reader in windows could not select the radio buttons, whereas firefox embedded viewer could. I then changed the export pdf settings in LO and marked "Archive (PDF/A ISO 19005)" and PDF/A version as PDF/A-3b, and the radio buttons were clickable and selected in default ubuntu document viewer and windows acrobat reader. Not sure if this is a solution or a workaround, but with that it works ;)
This is an intermittent issue in 6.4.6.2 (Ubuntu) and consistently broken on Windows 7.0.3.1 . At first I thought this was a cross platform issue where the PDF form I was generating on Linux was somehow broken and that could only be seen on Window's PDF viewers. Generating the form on Windows using the same source document and output settings confirms that it's the PDF rendering that's the problem. The PDF/A format work around mentioned here does not work. https://bugs.documentfoundation.org/show_bug.cgi?id=127217#c38 Now for whatever reason, it went from intermittent to consistently broken on 6.4.6.2-ubuntu. I've since switched to combo boxes as a work around but that brings with it the new problem of the foreground/background colors being difficult to see on Windows platforms [1]. It's good enough for now, but if this isn't fixed soon, we'll probably have to pony up for MS Word for the law firm. Which is a shame as the attorney has been using it as her primary word processor for years, it's only forms that are broken. We just can't spend days debugging forms when we're billing out at 250/hr. 1. https://www.petrakis.law/s/PetrakisLawClientIntakeForm_120320.pdf
LO 7.0.3.1 x64 running on Windows 10 Same problem here with radio buttons while exporting PDF as form : radio button not working into Adobe Acrobat DC reader. Workaround exporting document as PDFA-3/b not working. I've tried all exporting options combination. The forms works correctly if loaded with browsers (Chrome, Firefox, Edge). There is something strange: using Acrobat DC I see that the radio buttons *are clickable* but I don't see the black spot inside it ! So I cannot see evidence that the radio button was selected. Is it possible that was a spot colour problem ?
I forget to sat that with LO 6.2.8.2 Win x64, PDF forms are exported perfectly and radio buttons work fine. Now in my Windows 10 machine I removed all newer LO installation and installed 6.2.8.2 waiting this bug resolution.
Same problem here on Ubuntu 20.04 Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 12; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (en_US.UTF-8); UI: de-DE Ubuntu package version: 1:7.0.4_rc2-0ubuntu0.20.04.2 Calc: CL
I did not see as reference to this in this thread, just making sure it is visible. Quote from the link provided below: Radiobutton checked value bug: works in all pdf viewers except Acrobat Reader. Checked" radiobutton value is only working in Acrobat Reader when: * First radio button value is "0". * Radio button values are consecutive integers. https://community.adobe.com/t5/acrobat-reader/radiobutton-checked-value-bug-works-in-all-pdf-viewers-except-acrobat-reader/m-p/11410025 I hope this helps !
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a0d63ee5df921e5f1ac915ada783fdef0dbbb057 tdf#127217: Fix buttons in forms not working in Adobe Reader It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Backports waiting for review here: - 7.1: https://gerrit.libreoffice.org/c/core/+/112305 - 7.0: https://gerrit.libreoffice.org/c/core/+/112306
(In reply to Commit Notification from comment #44) > Affected users are encouraged to test the fix and report feedback. Works with the Daily from today. Great work, Thanks.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3faaad6d16881dbbd70e34dcb0445a3373f8ddad tdf#127217: vcl_pdfexport: Add unittest It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/fc337124c9bb7498fc84a1c60250d7c043e8c7a6 tdf#127217: Fix buttons in forms not working in Adobe Reader It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/70c33addf14d7ee9db874c0d653fbd8f035ac96e tdf#127217: Fix buttons in forms not working in Adobe Reader It will be available in 7.0.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: c18e5fd7d6c85d4755f1a70d97336d07b2add510 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Julien Nabet, thanks for fixing this issue!! Unittest is also added.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-1-2": https://git.libreoffice.org/core/commit/830fac3743c02ccd76fe2ca3b0a81e79ec697857 tdf#127217: Fix buttons in forms not working in Adobe Reader It will be available in 7.1.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I still have this problem with Writer under Linux: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: it-IT (it_IT.UTF-8); UI: it-IT Ubuntu package version: 4:7.6.4-0ubuntu0.20.04.1~lo2 Calc: threaded Depending on the reader (Xreader vs. Okular) I can flag radio buttons or not. In particular with Xreader I can't, but if I export in PDF the same document (ODT) from Windows then I'm able to flag them, even in Xreader.