Created attachment 159871 [details] Example showing descenders getting clipped **Overview**: When rendering highlighted text in a text box, descenders are clipped if they overlap with the next line of text. This does not happen if a fill is set for an entire textbox area. **Steps to reproduce**: Create a text box, set a highlight color, then resize the text box so it wraps below text containing glyphs with descenders (e.g., "g", "y", "p", "j"). **Actual results**: descending parts of "g", "y", "p", "j" glyphs are cut off where the next highlighted line starts. **Desired results**: The entirety of all glyphs should display in front of any highlight. **Version and hardware**: 6.4.3.2, build ID 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8, Ubuntu 18.04, Dell Latitude
Created attachment 159872 [details] Screenshot of bug
You have set a Paragraph format for line spacing to proportional 85%, the clipping is the typographic overlap caused by the reduced Paragraph spacing. Highlight applied to a line of text was not implemented to have any sense of intersection or transparency, nor is it necessary. Area fill of the draw Text Box is not affected as it is legitimately background to the text runs. If you don't like the affect on fonts with a compressed line spacing, find a font with correct metrics rather than abusing a font. IMHO => NAB @Tomaž, any different take on handling of highlighting for paragraphs with line spacing compressed below 100%? Should/could the highlighting have any sense of overlap?
Created attachment 159907 [details] text box with 85% line spacing with highlighting Here is a clip from attachment 159871 [details] with font corrected to Liberation Sans (since Barlow Condensed was unavailable and no subset) but still 85% proportional line space for the Paragraph. I've applied three runs of highlighting differing colors, extra spaces added to shift the last line. Note the highlight is applied in text run order, i.e. the first line is under the second is under the third. Clipping occurs because the highlight is not transparent nor modified to for the overlapping text runs. This is all correct, if you need the reduced "leading" aka line spacing, and still needed highlighting (rather than the adequate text box fill) you would need a different font. A font with reduced line height relative to point size--either with its internal leading, or reduced line height, referred to in type setting as a Bastard font for its non-standard sizing (larger or smaller font in a given point size).
Thanks for your comments. You're right that this behavior is only observed with line spacing below 1.0; good catch. I still do not understand why this behavior would be expected. For example, even when line height is reduced below 1.0, neither Powerpoint*, Google Slides, nor Keynote/Pages behaves like Impress. In Powerpoint, different highlight colors, if chosen, are still displayed in text run order as you mentioned, but the text is displayed in front of all of them. (I asked someone else to test Keynote/Pages and it looks similar to Powerpoint.) In Google Slides the highlight box itself seems to change with line-height, so that you only see a tiny amount of clipping if the line height is reduced so much that the glyphs themselves overlap. Impress is the only one that consistently displays entire lines of highlight over the top of text within the same box. Beyond whether or not Impress's behavior is "expected" or "correct," I am having trouble imagining a situation where it would be preferable in practice, as it has the worst effect on readability out of all the tested tools even at moderate reductions in line height. Your comment about leading being defined in the font itself is an interesting point. However, that seems to imply that LibreOffice should not allow line height to be reduced below 1.0 in the first place. On the other hand, LibreOffice already allows the user to override font specifications in ways that are technically "incorrect," for example, by drawing its own faux bolds and obliques for typefaces that don't provide these variants. * Incidentally, I think this also means that this behavior breaks compatibility with Microsoft Office. Highlight applied in Powerpoint appears to either be missing entirely, if saved as a .pptx and imported, or displayed in front of text, if saved as a .odp.
Created attachment 159914 [details] Comparison of highlighting overlap for PowerPoint, Google Slides, and Impress (top to bottom)
Hello Patrick B, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Patrick B., 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 Patrick B., 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