Description: When you put a semitransparent background in a text area on top of a black element, the black is gray (as expected). But if you press enter and type a new line, you will get a white line. It does not appear if you use SHIFT-Enter. Steps to Reproduce: 1. Open attached document 2. See the 3rd line (on my screen it looks like the image below) Actual Results: There is a white line. Expected Results: There should be no white line. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.10 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 160013 [details] File with the white line
Repro in: Version: 6.3.3.2 (x64) Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU tråde: 8; Styresystem: Windows 10.0; Gengiver af brugergrænseflade: Standard; VCL: win; Lokalisering: da-DK (da_DK); Sprog for brugergrænseflade: da-DK Calc: threaded
Repro in: Version: 6.4.3.2 (x64) Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU tråde: 8; Styresystem: Windows 10.0 Build 18363; Gengiver af brugergrænseflade: Standard; VCL: win; Lokalisering: da-DK (da_DK); Sprog for brugergrænseflade: da-DK Calc: threaded
Created attachment 160175 [details] Test case - now with screenshot
I can confirm it with Version: 7.0.0.0.alpha0+ (x64)Build ID: 8c8b3a4f83f67882b284ddc3b3fe10d3fe6dedf4CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GBCalc: CL But i think, this is not specific to transparency or text on shapes: If you set a paragraph background color in an new document, you get the same behaviour. There is always a thin line visible between paragraphs. Don't know, if this is a bug. cc: Design-Team
(In reply to Dieter from comment #5) > But i think, this is not specific to transparency or text on shapes: If you > set a paragraph background color in an new document, you get the same > behaviour. There is always a thin line visible between paragraphs. Don't > know, if this is a bug. Cannot confirm this (but the issue with transparency). Thought it's related to spacing, set to 1.15 lines, but even with single line distance the size is not calculated correctly. Not an UX issue. PS: I wonder why wrapping of your version info is broken. "Copy Version Info" returns for me: Version: 7.0.0.0.alpha0+ Build ID: 1bc96e1d9c4d372761ac4b6a2891cbcc3768a60f CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3; Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 160380 [details] clip at single line spacing with highlighting applied, incorrect height of transparent attribute When I reduce the line spacing to single / proportional 100% and apply highlighting--the coverage of the highlights fully align/match. But for text of the paragraph only set transparent--the calculation of transparency is not the full height of the line--there is extra leading. Incorrect transparency rendering.
The line is also visible when printed. So it is not just an artifact on the screen.
Dear Ole Tange, 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
Still present in Version: 7.3.3.2 (x64) / LibreOffice Community Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348 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
Unfortunately, the bug is still present in version 7.5.3.2 Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 6; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (en_US); UI: en-US Calc: threaded It was also present in the most recent master build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e4c611ddc731d6a2ca9c3de61a02d1d4b6eefa9b CPU threads: 6; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded