Description: After creating a form in writer for a fillable pdf, and setting the tab/activation order, the tab order has changed in pdf readers. Steps to Reproduce: 1.Build single page form document in Writer. 2.Set tab/activation order 3.Export to FDF, archive or tagged pdf 4. Open in any reader that allows tabbing, and the tab order will have changed. Actual Results: Tab order had changed Expected Results: Tab order should not change Reproducible: Always User Profile Reset: No Additional Info: Nothing to add. Will send file once bug report is filed.
Created attachment 184563 [details] File that demonstrates problem File that demonstrates problem
Created attachment 184576 [details] File that shows problem, but is sanitised for contact details. Removed sensitive personal data from earlier file.
Created attachment 184577 [details] pdf output file, with tab order errors. File (pdf) displaying tab/activation order errors.
I have worked out what the problem is. The activation/tab order is not followed if one text box is slightly higher than another. For instance, if the tab order is set to textbox 1, text box 2, text box 3, text box 4, and text box 4 has a Position Y that is smaller than that of text box 3, text box3 will be tabbed to first. The new simplified attachment shows this.
Created attachment 184660 [details] Simple form to demonstrate tab order Simple example test file
Writer form for simple pdf.
Created attachment 184661 [details] writer file to create pdf demo
Have tested with 4 text controls, which had to been set to single line. Created the tab order. Tabulator jumps to the controls I defined with tab order: Up left, down left up right down right. Couldn't see a buggy behavior here. Tested with Version: 7.4.4.2 / LibreOffice Community Build ID: 85569322deea74ec9134968a29af2df5663baa21 CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Please add a Writer file with a form with wrong tabbing order. Please add the version of LO you are using for creating this form.
Try moving one of the text boxes to a slightly higher position on the page. On my system, this changes the tab order. I do not have tabbing order set to automatic.
(In reply to Mike Sapsard from comment #9) > Try moving one of the text boxes to a slightly higher position on the page. > On my system, this changes the tab order. I do not have tabbing order set to > automatic. Tried it. Tab order in Writer form an tab order in exported PDF is the same. If I won't set the tab order for a field the tab order will work as follows: Upper left corner to upper right corner. All control fields that lie further below are later accessed with the tabulator. Why didn't you show the Linux-version you are using here? Might be you are using a version of your distribution, which could have special buggy behavior. Why didn't you add a little form, which shows the buggy behavior. It should be a Writer document, not exported pdf documents. So everybody might see: Tab order in Writer document isn't the same as in pdf-document. I couldn't confirm any bug here. Tested with LO 7.4.4.2 on OpenSUSE 15.3 64bit rpm Linux.
(In reply to Robert Großkopf from comment #10) > Why didn't you show the Linux-version you are using here? Might be you are > using a version of your distribution, which could have special buggy > behavior. > Why didn't you add a little form, which shows the buggy behavior. It should > be a Writer document, not exported pdf documents. So everybody might see: > Tab order in Writer document isn't the same as in pdf-document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information and document.
These are my Linux details: Kernel: 5.15.0-67-generic x86_64 bits: 64 compiler: gcc v: 11.3.0 Desktop: Cinnamon 5.6.8 tk: GTK 3.24.33 wm: muffin dm: LightDM Distro: Linux Mint 21.1 Vera base: Ubuntu 22.04 jammy
(In reply to Mike Sapsard from comment #12) > These are my Linux details: > > Kernel: 5.15.0-67-generic x86_64 bits: 64 > compiler: gcc v: 11.3.0 > Desktop: Cinnamon 5.6.8 > tk: GTK 3.24.33 > wm: muffin > dm: LightDM > Distro: Linux Mint 21.1 Vera > base: Ubuntu 22.04 jammy Ok, now you should also copy and paste here the contents of your Help - About (LibreOffice - About on macOS) by clicking the copy button and also attach an example document.
Dear Mike Sapsard, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Mike Sapsard, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
from meta.xml of OPs sample ODF attachment 184576 [details] LibreOffice/7.4.3.2$Linux_X86_64 LibreOffice_project/1048a8393 1. open attachment 184576 [details] in writer 2. place into design mode (Form -> Design Mode) 3. open form navigator dialog (Form -> Form Navigator...) 4. open form tab order dialog (Form -> Activation Order...) 5. verify the tab order while in writer follows the sequence in the 'Tab Order' activation order dialog; while noting it differs from the sequence in the 'Form Navigator' 6. Export as PDF, use the Create PDF form checkbox with the FDF template 7. open the resulting PDF in Adobe Reader and use its Fill & Sign mode 8. the tab order does not match the sequence of the 'Activation Order...' dialog rather seems to follow the *raw* sequence of the 'Form Navigator...' Also did a 2nd export having exited design mode (so no involvement of bug 94596), same result IMHO an issue with the PDF export filter. =-testing-= Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to V Stuart Foote from comment #16) > from meta.xml of OPs sample ODF attachment 184576 [details] > > LibreOffice/7.4.3.2$Linux_X86_64 LibreOffice_project/1048a8393 Why do you test with such an old version. Tested again, now, with LO 7.6.2.1, OpenSUSE 64bit rpm Linux. > 8. the tab order does not match the sequence of the 'Activation Order...' > dialog Here the tab order is exactly the tab order of the *.odt-Document. I open the document, set the cursor in field for tabulator '1' ("Bank Transfer"). It's the field, which will be chosen by automatic order. Tab moves to "Join", then to "Name", "Mem No.", "Mobile" … Exported document in PDF does the same here with Okular. The automatic tab order will have a look at the position of the fields. Y-Position decides first, Y-Position second. So it starts with "Bank Transfer". It is positioned at first position. It doesn't change to "Cheque", because it is a checkbox for the same control name. Only one could be chosen. Question: Where do you see a tab order, which differs from the tab order in Writer?
I thin you will find that in January 2023, that old version of LO was the current version. I thought I had commented that the problem was no longer there.
(In reply to Mike Sapsard from comment #18) > I thin you will find that in January 2023, that old version of LO was the > current version. > I thought I had commented that the problem was no longer there. So let us set this bug to WORKSFORME.
(In reply to Robert Großkopf from comment #17) > > Question: Where do you see a tab order, which differs from the tab order in > Writer? Hi Robert, the issue is not with document opened in Writer. Rather it is with tab movement between fields of the exported PDF opened in Adobe Reader (Core ver. 23.1536 x64 on Win10). That movement sequence looks to match the field sequence as listed in the LO 'Form Navigator...' dialog as opened in Writer with the ODT being edited.
Confirmed steps in comment 16, using Adobe Reader. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cb46ad4c4602fbb6aeab482e9370e31495e12cfe CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #21) > Confirmed steps in comment 16, using Adobe Reader. > So I can't test here. With Okular an Foxit Reader (Wine) it runs well under OpenSUSE 15.4. Seems Adobe Reader doesn't read tabstops …
I use LinuxMint Document Reader, Ocular and Foxit to test. They all gave the same results on tabbing.
(In reply to Mike Sapsard from comment #23) > I use LinuxMint Document Reader, Ocular and Foxit to test. They all gave the > same results on tabbing. That's strange: Okular gives me a different result (advancing logically) from Adobe Reader.
Comment from dev chat: 'Probably someone needs to debug how Adobe does this, I would suggest building a test document using this: https://acrobatusers.com/tutorials/how-do-i-set-up-tab-order-in-a-form/ and then seeing how the output PDF compares to our PDF. But that essentially makes this less of a bug and more of a feature request in the sense of "make our output pdf have more magic to make Acrobat happy"' It seems like a job for professional support https://www.libreoffice.org/get-help/professional-support/
Found a solution that results in correct behavior of Acrobat. In PDF Options the flag "Tagged PDF (add document structure)" needs to be unchecked. Then a specific tab sequence is correctly handled by Acrobat Reader. By default the flag is set when libre office is installed new. Tested in this environment: In Libre Office Writer version 7.6.4.1 Acrobat Reader 2023.008.20470 Windows 11 Ürp - 10.0.2261 Build 2261