Description: Creating a new master slide with a dark background automatically changes the text to a lighter colour, as expected. When this master is applied to a slide, the colour of the text changes in the displayed slide (as it should), but when one attempts to print the slide, the text reverts to the default black making it unreadable on top of a dark background. Manually changing the text colour on each slide addresses this issue, but obviously isn't an ideal solution for large presentations. Steps to Reproduce: 1. Create a new master slide with a dark background. The text will automatically become light coloured. 2. Create a slide from a this new slide master. 2. Go to "Print" under file. 3. Select "Handouts" under the document dropdown box. 4. Check the print preview generated in the "Print" dialog box. Actual Results: Text remains the default black colour when printed (visible in print preview). Expected Results: Text should stay the same colour as is displayed before trying to print. Reproducible: Always User Profile Reset: Yes Additional Info: It seems like this is an issue with the slide master applying the colour change to the text as displayed, but then not applying the colour change to the printed slides or handouts. Note that the change has to be done to the slide master--if the background colour is changed for an individual slide using the slide properties dialog box, the modified text colour is displayed properly when printing. About info: Version: 6.2.0.3 (x64) Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-CA (en_US); UI-Language: en-US Calc: threaded
Thank you for reporting the bug. I can not reproduce the bug in Version: 6.2.1.2 (x64) Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL Version: 6.3.0.0.alpha0+ (x64) Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10 Locale: en-US (en_US); UI-Language: en-US Calc: CL
I am still getting the same dark text on a dark background on 6.2.2.2. Strangely the text in the title changes colour on printing as expected but the text within the slide does not. For anyone else having this issue, you can manually change the text colour in the master to a lighter colour and the slides will print with the correct lighter coloured text that is displayed. Seems to be an issue only with the automatic text colour within the slide master.
Please attach an example document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
Created attachment 151259 [details] 3 slide file showing example of bug 1st slide shows expected behaviour with default dark text and light background (default master). 2nd slide shows bug when master is applied to slide with dark background with light (automatic)text--printed text is still dark. Note that when light text is manually selected on the master it is applied to the printed slide as displayed. 3rd slide shows expected behaviour with manually selected dark background and light text. The easy workaround is to just always remember to manually select light coloured text when using a dark background. The automatic light coloured text is not being applied to the slide body when printing though.
Thanks for the file. Already seen in the oldest commit of win32-4.3 bibisect repo. In 3.5.0, the text colour is black even in slide edit view. Going to call this an implementationError therefore. It's funny that on Linux, the text in slide 2 is fairly dark gray in slide edit mode.
Dear Colin S, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Colin S, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug