Description: Open the attachment 182846 [details]. There are content control and other fields on the first page, and the background and style used for them are different in LibreOffice. On the other hand, if you load the same file in MS Word, the background and style for the placeholder text is the same. Steps to Reproduce: 1. Open the attachment 182846 [details] 2. See page 1 Actual Results: The background and style for the placeholder text is the different. Expected Results: The background and style for the placeholder text should be the same. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 022eafa4d69bc8290aa304b69af2c325fe3d2a02 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fa-IR (fa_IR); UI: en-US Calc: threaded
Created attachment 183708 [details] Background and style in MS Word
Created attachment 183709 [details] Background and style in LibreOffice
Reproduced in master build from today: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 24d7431876e87eba700a9f141dc8e030143a92ad CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Field shading can be changed in Tools > Options > LibreOffice > Application Colors > Custom Colors > Text Document > Field shadings. Not sure where the colour for content control comes from. Either we use the same colour as fields, or if there is justification for it, we keep the colours separate but expose the setting in Custom Colors?
(In reply to Stéphane Guillou (stragu) from comment #3) > Not sure where the colour for content control comes from. Form controls (guess that's what you mean with "content control") take their color from the OS/DE background. In my case with KDE and a dark Breeze theme it's always very dark. Might have improved with the latest work by Caolan, but not adding customization. I wonder what ticket we should use as duplicate: bug 151936 Changing text color of form control (textbox) doesn't work bug 132827 Form-control: Setting Font Color to Automatic switches back to Black in Dialog bug 139402 FORMATTING: Default font color for form controls is set to black but displays as gray bug 106810 set transparent background color in form controls (Not having looked into the comments transparency sounds reasonable.)
(In reply to Heiko Tietze from comment #4) > Form controls (guess that's what you mean with "content control") take their > color from the OS/DE background. In my case with KDE and a dark Breeze theme > it's always very dark. Might have improved with the latest work by Caolan, > but not adding customization. In this case were are talking about content controls which have more support since 7.4, and have less options than the form controls we've had for a while. The customisation options for content controls (Form > Content control > Content control properties) are very different to form controls and do not contain any options to change colours. In any case, content controls created from scratch in LO (e.g. rich text, drop-down list...) have the same default background as fields (e.g. page number). The issue Hossein describes here seems to be related to DOCX import of content controls: same look in MS Word but different when imported in LO. Looks like fields automatically take the colour set in the LO Application Colors, but content controls keep the formatting they had in MSO. Am I missing something? I feel like I might be...
Talked with Stéphane about the issue. Now I know that Content Controls are listed at the bottom of the Forms menu. However, adding something in MSO worked for me. So we went back to the document from comment 0. It has all kind formatting, PS, CS, DF - and if you remove direct formatting it will be shown in the same color as fields. So probably NAB (needinfo for Hossein to make sure nothing has been missed).
Dear Hossein, 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 Hossein, 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