Download it now!
Bug 127217 - PDF export: LibreOffice 6.3 option buttons in forms not working in Adobe Reader (OK in other readers)
Summary: PDF export: LibreOffice 6.3 option buttons in forms not working in Adobe Read...
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All All
: highest normal
Assignee: Thorsten Behrens (CIB)
URL:
Whiteboard:
Keywords: bisected, needsDevAdvice, regression
: 127917 128020 128664 128822 130891 131690 134813 136849 137554 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2019-08-29 13:12 UTC by b3_1987
Modified: 2020-10-18 01:29 UTC (History)
22 users (show)

See Also:
Crash report or crash signature:


Attachments
Test ODT (14.46 KB, application/vnd.oasis.opendocument.text)
2019-08-30 09:09 UTC, Timur
Details
tail of terminal output from bibisect in 64-6.3 repo (2.97 KB, text/plain)
2019-08-31 20:28 UTC, Terrence Enger
Details
Invoer.odt - testcase (9.88 KB, application/vnd.oasis.opendocument.text)
2020-02-25 08:07 UTC, Hans Dijkema
Details
The PDF generated with LO 6.4.0 (16.25 KB, application/pdf)
2020-02-25 08:08 UTC, Hans Dijkema
Details
The PDF generated with LO 6.2.8 (16.54 KB, application/pdf)
2020-02-25 08:34 UTC, Hans Dijkema
Details
Two radio buttons in odt file (8.56 KB, application/vnd.oasis.opendocument.text)
2020-07-07 08:54 UTC, Jack
Details
Two radio buttons in pdf file before changes made by the "Preview" app. (7.88 KB, application/pdf)
2020-07-07 08:55 UTC, Jack
Details
Two radio buttons in pdf file after changes made by the "Preview" app. (10.41 KB, application/pdf)
2020-07-07 08:55 UTC, Jack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description b3_1987 2019-08-29 13:12:51 UTC
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.
Comment 1 Timur 2019-08-30 09:08:17 UTC
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.
Comment 2 Timur 2019-08-30 09:09:19 UTC
Created attachment 153749 [details]
Test ODT

Reporter had better attached a sample. I'm doing it now.
Comment 3 Terrence Enger 2019-08-31 20:28:15 UTC
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.
Comment 4 Timur 2019-10-03 12:53:31 UTC
*** Bug 127917 has been marked as a duplicate of this bug. ***
Comment 5 Oliver Brinzing 2019-10-08 17:34:01 UTC
*** Bug 128020 has been marked as a duplicate of this bug. ***
Comment 6 Frank Rowe 2019-10-09 04:51:41 UTC
OK @Oliver Brinzing
Comment 7 Oliver Brinzing 2019-11-08 17:33:25 UTC
*** Bug 128664 has been marked as a duplicate of this bug. ***
Comment 8 Oliver Brinzing 2019-11-15 18:54:56 UTC
*** Bug 128822 has been marked as a duplicate of this bug. ***
Comment 9 Hans Dijkema 2020-02-25 08:07:54 UTC
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
Comment 10 Hans Dijkema 2020-02-25 08:08:28 UTC
Created attachment 158165 [details]
The PDF generated with LO 6.4.0
Comment 11 Hans Dijkema 2020-02-25 08:34:11 UTC
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
Comment 12 Hans Dijkema 2020-02-25 08:35:47 UTC
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).
Comment 13 Oliver Brinzing 2020-02-25 17:40:01 UTC
*** Bug 130891 has been marked as a duplicate of this bug. ***
Comment 14 Oliver Brinzing 2020-03-30 18:08:49 UTC
*** Bug 131690 has been marked as a duplicate of this bug. ***
Comment 15 Georg 2020-04-09 08:00:42 UTC Comment hidden (no-value)
Comment 16 Jack 2020-07-07 08:50:52 UTC Comment hidden (me-too)
Comment 17 Jack 2020-07-07 08:51:17 UTC Comment hidden (obsolete)
Comment 18 Jack 2020-07-07 08:54:01 UTC
Created attachment 162743 [details]
Two radio buttons in odt file
Comment 19 Jack 2020-07-07 08:55:02 UTC
Created attachment 162744 [details]
Two radio buttons in pdf file before changes made by the "Preview" app.
Comment 20 Jack 2020-07-07 08:55:42 UTC
Created attachment 162745 [details]
Two radio buttons in pdf file after changes made by the "Preview" app.
Comment 21 Steve Coleman 2020-07-26 02:40:37 UTC
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.
Comment 22 Georg 2020-08-07 09:46:52 UTC
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.
Comment 23 Timur 2020-09-19 15:39:47 UTC
*** Bug 134813 has been marked as a duplicate of this bug. ***
Comment 24 Timur 2020-09-19 15:42:13 UTC
*** Bug 136849 has been marked as a duplicate of this bug. ***
Comment 25 Timur 2020-09-19 15:48:28 UTC
Xisco, please see to revert this commit. Fix is worse for more users than original issue, which can be reopen with normal priority.
Comment 26 Timur 2020-09-19 15:52:58 UTC
This is the last chance for fix in LO 6.4.7.
Comment 27 Dirk Munk 2020-09-19 16:27:35 UTC Comment hidden (no-value)
Comment 28 Dirk Munk 2020-09-19 16:47:42 UTC
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.
Comment 29 Dirk Munk 2020-09-19 20:02:40 UTC Comment hidden (no-value)
Comment 30 Dirk Munk 2020-09-24 14:01:09 UTC Comment hidden (no-value)
Comment 31 Joel M 2020-09-24 14:23:28 UTC
(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.
Comment 32 Thierry 2020-09-26 16:18:34 UTC
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...
Comment 33 V Stuart Foote 2020-10-17 17:35:40 UTC
*** Bug 137554 has been marked as a duplicate of this bug. ***