Steps to reproduce: 1. Open attachment 182776 [details] from bug 151261 2. Choose any value in the dropdown list 3. Save it to PDF -> There is an empty space in the dropdown list. The chosen value should have been displayed instead. Tested with Evince, Firefox and Chrome Reproduced in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b9411e587586750f36ba9009b5f1e29fe461d8b5 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: de-DE (es_ES.UTF-8); UI: en-US Calc: threaded
Hi Miklos,
Hi Miklos, I thought you might be interested in this issue, since it's part of your SDT work you implemented recently
I confirm it with Version: 7.5.0.2 (X86_64) / LibreOffice Community Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded
Changed from plain text into an empty text input field with LO 7.5 commit 82d90529dc2b3cb8359dec78852cbd910a66d275 Author: Miklos Vajna on Mon Sep 12 09:30:38 2022 +0200 sw content controls, rich text: add initial PDF export and later was turned into a pre-filled text box with LO 7.5 commit 122419be4f7bf576f7db5456b8b6b1f6f700487f Author: Miklos Vajna on Mon Oct 24 08:45:26 2022 +0200 sw content controls, alias: add PDF export
I think I corrupted my test document in the last comment. This time I looked for when it turned into the current situation, where we have a dropdown in the PDF. I bibisected it to 7.5 commit f726fbc2699b05199a8dec3055710a7131e0aad6 Author: Miklos Vajna on Mon Oct 10 10:07:10 2022 +0200 tdf#151261 DOCX import: fix dropdown SDT when the item display text is missing This went from an empty text input field to an empty dropbox field.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7daf830830609cbb13a01ae55634187718c84d8a tdf#153040 sw content controls PDF export: output listbox entry It will be available in 7.6.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.
Justin, you can mark as Resolved. The dropdown element is in PDF in Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: c50e4b25b2eb278685698182e2a4b541739f2d42 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded But not in (for reference of testing the fix) Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
backport is on it's way. There are a couple of concerns here still. 1.) the text doesn't quite fit in the provided space - the last letter "fades out". 2.) the drop-down now fits the size of the selected text. That means any longer choice won't fit any more. (That's good for print fidelity, but not form-filling. Forms would need to space-pad their names.)
Created attachment 187702 [details] DropDownListB.docx: expose the dilemma - print fidelity or forms filling If "strawberry" is chosen, then "with" moves down to the next line. (Also clearly seen is the minor spacing adjustment that comes before the content control. Additionally, the font changed for the two text controls.)
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/2c813b3745e2da2001d318a60d911107bfefc32c tdf#153040 sw content controls PDF export: output listbox entry It will be available in 7.5.5. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/026924b192031769449814b9166a7b8d37c869f8 tdf#153040: unit test It will be available in 7.6.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.
I made a patch to turn off "create PDF form" by default since the PDFs we create that contain content controls are actually really poor. https://gerrit.libreoffice.org/c/core/+/152622 However, I do not fell comfortable having my name associated with this change. There seem to be some internal PDF structures that depend on forms being enabled in order for some unit tests to pass. They don't really seem to be involved in export in the normal process. However, I don't like being required to have some parts of LO default to true and other parts default to false. So I will abandon that patch and leave it to PDF people to pick it up if they want it. This particular bug report is solved (with the caveats noted).
Created attachment 188505 [details] bug_153040_Foxit_does_not_render_content_of_drop_down
Created attachment 188506 [details] bug_153040_Chrome_after_open
Created attachment 188507 [details] bug_153040_Chrome_after_click_on_dropdown
I have exported attached DOCX in LO 7.5.5 and the content is not displayed. As in listed attachments: bug_153040_Chrome_after_click_on_dropdown.png bug_153040_Chrome_after_open.png bug_153040_Foxit_does_not_render_content_of_drop_down.png Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: threaded
Created attachment 188508 [details] DropDownListB_7.5.5.pdf File exported in: Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: threaded
Created attachment 188509 [details] bug_153040_Firefox_after_open.png Firefox preview looks better.
Dropdown list isn't empty now, but I don't know if actual result is really the expected result (see attached screenshots). Tested with Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded
Created attachment 189009 [details] Result with Acrobat Reader
Created attachment 189010 [details] Result with Chrome
Created attachment 189011 [details] Result with Firefox
(In reply to Justin L from comment #8) > backport is on it's way. > > There are a couple of concerns here still. > 1.) the text doesn't quite fit in the provided space - the last letter > "fades out". > 2.) the drop-down now fits the size of the selected text. That means any > longer choice won't fit any more. (That's good for print fidelity, but not > form-filling. Forms would need to space-pad their names.) These problems still remain, but since original problem has been solved, I will change status to VERIFIED Justin, thank you for your work!