Steps to reproduce: 1. Open attachment 87024 [details] from bug 70066 2. Export it to PDF -> The text fields in the footer are empty. They should show "[Type text]" instead. 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 [Bug found by office-interoperability-tools]
Regression introduced by: author Miklos Vajna <vmiklos@collabora.com> 2022-09-12 09:30:38 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2022-09-12 10:16:11 +0200 commit 82d90529dc2b3cb8359dec78852cbd910a66d275 (patch) tree 427c2458c4c039aaced2c38310881bb19891645c parent 7458cb8d13b2893ccbfb648198319cc3a73d7e50 (diff) sw content controls, rich text: add initial PDF export Bisected with: bibisect-linux64-7.5 Adding Cc: to Miklos Vajna
I believe this is an intentional change. We used to export content controls as plain text, and now we export them as PDF form widgets if the "create pdf forms" option of the PDF export is enabled. That option happens to be on by default. Is there something I can fix here without breaking the use-case where you can insert content controls to a Writer document, export it as PDF and you get a fillable form, similar to what also works with control shapes? Should we disable "create pdf forms" by default?
Hm, if we change something here at all, then that would be a change in the new content control feature, so it's rather an implementation error. Adjusting keywords accordingly.
(In reply to Miklos Vajna from comment #2) > I believe this is an intentional change. We used to export content controls > as plain text, and now we export them as PDF form widgets if the "create pdf > forms" option of the PDF export is enabled. That option happens to be on by > default. > > Is there something I can fix here without breaking the use-case where you > can insert content controls to a Writer document, export it as PDF and you > get a fillable form, similar to what also works with control shapes? > > Should we disable "create pdf forms" by default? no, no, I don't think it should be disable by default. My thinking was: if the content controls have a default text ( like "[Type text]" in this case ), should it be exported to PDF if the user doesn't writer anything to the control or should be exported as empty ?
Here is a patch to do what you request: > diff --git a/sw/source/core/text/itrform2.cxx b/sw/source/core/text/itrform2.cxx > index 9f075014fd9a..8756a712dc44 100644 > --- a/sw/source/core/text/itrform2.cxx > +++ b/sw/source/core/text/itrform2.cxx > @@ -1089,7 +1089,6 @@ void SwContentControlPortion::Paint(const SwTextPaintInfo& rInf) const > > if (DescribePDFControl(rInf)) > { > - return; > } > > SwTextPortion::Paint(rInf); With this, if I open the PDF in okular on Linux or acroread on Windows, and type "asdf" into the footer's center field, I can overlapping text and it's impossible to get rid of that, because the PDF reader can't know that's placeholder text for the field when it's not yet filled in. At least for me it looks like the attached overlap.png. (in Okular, click on "show forms" to be able to fill in the form, then "hide forms" to see how it would be rendered). So that's not going to work, I believe. If you want to provide placeholder text in a content control, then you need to go form -> content controls -> content control properties, fill in the "title" field, and that'll be provided as the default value for the PDF form. And that default value will disappear when you fill in the form. Hmm, here is an idea: what about we keep the current behavior, but in case title is empty, then we export the text of the content control as the default value of the PDF form widget instead of not exporting anything? I believe that won't upset anybody and you'll get a better PDF export for these documents. Would that work?
Created attachment 184757 [details] Overlap if text of content control would be exported unconditionally and the form is filled.
(In reply to Miklos Vajna from comment #5) > Hmm, here is an idea: what about we keep the current behavior, but in case > title is empty, then we export the text of the content control as the > default value of the PDF form widget instead of not exporting anything? I > believe that won't upset anybody and you'll get a better PDF export for > these documents. Would that work? Yes, it sounds like a good solution :-)
[Automated Action] NeedInfo-To-Unconfirmed
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/14da39fcfffe8006a79971ac0b670e12d0d7a0ea tdf#153047 sw: fix PDF export of content controls in placeholder mode 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.
Verified in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9b9159aa9073318c6892787d721b8cd732525972 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: de-DE (es_ES.UTF-8); UI: en-US Calc: threaded @Miklos, thanks for fixing this issue!!
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/e80593e219dffd85ab16ebd2954cba8fa8c84637 tdf#153047 sw: fix PDF export of content controls in placeholder mode It will be available in 7.5.1. 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.