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.
The option (radio) buttons cannot be checked (marked as selected).
The option buttons should be selectable, as they are in the PDF files exported in LibreOffice 6.2.
User Profile Reset: No
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
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]
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
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:
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
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 6ec26ba3aa195eac62fb8803137070d23a69491c)
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
* 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 126.96.36.199, 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: 188.8.131.52
Build ID: 184.108.40.206-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 220.127.116.11 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. ***