Created attachment 182336 [details] Document that can reproduce the bug I started a little project (see https://gitlab.com/schrieveslaach/nextcloud-open-document-forms) in which I use the LibreOffice CPP API to generate a PDF document from a ODT document with form fields. However, I my project the text is always hidden behind a white rectangle. The text seems to rendered behind the form outline. To reproduce the issue: You can git clone the project, use setsdkenv_unix to set up the LibreOffice SDK and run cargo run (Rust toolchain required) to start an HTTP server. When you open the URL http://127.0.0.1:8000/, you can enter a name into the form and submit it. The resulting PDF will contain the entered name (use ctrl + a to select all text), but it will be invisible. The same happens, when you export the attached ODT as PDF in LibreOffice Writer.
Created attachment 182337 [details] PDF export result in 7.4 Hm, if I open your ODT in Writer, type "asdf" into the "text box" form shape and export to PDF, I get the attached. That looks reasonable to me: I can toggle in e.g. okular if I want to see the forms or not, and both the plain PDF view and the "show forms" one shows "asdf" to me. Care to elaborate where is it missing? It may be a good idea to try at least 2 PDF viewers to make sure that the problem is with the PDF, not with the viewer.
Created attachment 182338 [details] Exported with LO 7.4 on Arch Linux
The text in “PDF export result in 7.4” is visible to me as well so I won't suspect that the PDF viewer is to blame (tried multiple ones and all show the same result). I attached an exported PDF document that has been generated on my machine.
More detailed version info: Version: 7.4.2.0.0+ / LibreOffice Community Build ID: 7a7268be9cbeaf361cfa5a52ad8980214e958f2e CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Can you provide your one from the about dialog? Perhaps we regressed in some older 7.4 and this got fixed?
Here are my version information. Version: 7.4.0.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE 7.4.0-3 Calc: threaded Please note, that the issue was also present in 7.3. I also unticked the box to generate a PDF form in the PDF export dialog so the text won't be editable. The attached document “PDF export result in 7.4” is a PDF form. Exporting PDF forms generates the same result on my system.
[Automated Action] NeedInfo-To-Unconfirmed
I don't reproduce the bug. You were not precise, you attached ODT with empty form and say that it makes empty form, which it should. So far this seems more for support at ask.libreoffice.org then for bug report here. You may try with empty profile of LO user folder.
To reproduce with LO: Open “Document that can reproduce the bug” and enter a text into the text field. Go to file -> export as -> export as PDF and make sure that you do not check the box to export a PDF form. Then export. When you open up the exported PDF, you can mark the text with ctrl + A and copy/paste it into a text editor. This will copy “First name:” and the entered text. But that text is invisible in the PDF document. Please note that my first comment included the instructions how to reproduce the bug with https://gitlab.com/schrieveslaach/nextcloud-open-document-forms
We couldn't reproduce, meaning some detail is missing or you need to follow what's advised - You may try with empty profile of LO user folder. Please do not set Unconfirmed indicating need for testing, unless you have more details, as test was done by 2 persons and it has no purpose staying like that.
Created attachment 182607 [details] A screencast that shows how to reproduce I made a screencast that show how I can reproduce the bug. The screencast also shows that I'm using a fresh profile folder (see soffice -env:UserInstallation=file:///tmp/test) and I opened the ODT from here (https://gitlab.com/schrieveslaach/nextcloud-open-document-forms/-/blob/main/example-docs/firstname.odt). Copying the text from the exported PDF into a text editor shows that the text is there but invisible.
And I must apologize. My project did not initialize the LO backend so that it is reproducible because I wasn't aware that the LO API picks up the settings of my LO profile. The commit https://gitlab.com/schrieveslaach/nextcloud-open-document-forms/-/commit/46b0f2974d1044719a14bc764f52591bb19dce51 starts the backend now in the same way as in my screencast. So if you checkout the project and if you follow the instruction, test PDF should be generated in the same way.
I may have an explanation: you are using German interface but English text so text is lost ? :) Or another one: you are using dark mode in Linux. It was some detail.. If form is not exported, it's content is light or not seen on white background. If form is exported, it's dark with light text. Could be a dupe of bug 150786, but so far let's keep that one Win and this one Lin.
(In reply to Timur from comment #14) > Could be a dupe of bug 150786 While difference in control background is indeed bug 150786, the problem here is that the text has the same color. But I can't repro this last piece on my Ubuntu system: the text is white on black when I set system to dark mode.
(In reply to Mike Kaganski from comment #15) > I can't repro this last piece on my Ubuntu system: > the text is white on black when I set system to dark mode. Ah, sorry - yes, exporting with disabled creation of PDF form in dark mode gives slightly grey text on white control area. But I'm unsure if it's related to bug 150786.
This one hits Edit::Draw so putting a breakpoint there shows how it gets called, which is from VclMetafileProcessor2D::processControlPrimitive2D etc. Ideally I think we would distinguish a form control hosted in a document as different to one hosted in, say a dialog, but its not entirely clear to me where the right place would be for that distinction to be made.
we have an existing "NativeWidgetLook" property so maybe we can leverage its absence to force 'standard' colors for UnoControl::draw
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ea36e0502c0bc381577cfa1b1a7fedf0f05d1d72 tdf#150786 use a 'standard' theme for form controls It will be available in 7.5.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.