Created attachment 124371 [details] Incorrect rendering of box style As you can see on the 4th bullet in the attached screenshot, the box around PERF is cut off on the left side. A few more bullets down, you can see how it should look. I created a style that includes the border around the text. Also, related to another bug report I've written, when a symbol character is inserted into a line, the spacing on that line is compressed or otherwise all messed up. On that same 4th bullet, you can see the extra space between --> (6L). Note: The single character arrow was created automatically when I typed --> then hit the space bar.
Hello, Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document. (Please note that the attachment will be public, remove any sensitive information before attaching it.) How can I eliminate confidential data from a sample document? https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F Thank you
Created attachment 124813 [details] Boxed text cutoff example In this document you can see the bullet character and space cuts off the boxed text style.
Dear Bug Submitter, 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-20161108
Dear Bug Submitter, 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-20161207
I am seeing this too in: Version: 6.1.0.2 (x64) Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group threaded Steps to reproduce: 1. New Writer document. 2. Type "The following is a list of items:", press Enter. 3. Type "Item 1", press Enter. 4. Type "Item 2", do not press Enter. 5. Select Item 1 and Item 2. 6. Format > Character... > Borders > Presets: Set All Four Borders. OK. 7. Click on the "Toggle Bulleted List" button in the toolbar. Bad behavior should appear: borders are cut. There is no way to just set the behavior to the text without including the bullet.
Created attachment 145002 [details] simple document
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f8b6c3949e2c1f23549a2ef879e728cdb7149235 author Zolnai Tamás <zolnaitamas2000@gmail.com> 2013-08-21 21:30:41 +0200 committer Zolnai Tamás <zolnaitamas2000@gmail.com> 2013-08-23 21:01:37 +0200 commit f8b6c3949e2c1f23549a2ef879e728cdb7149235 (patch) tree 256fc0266b2f32d3cc2c868f26c954c8ecc21a04 parent 9509a46683e40fc2feea6631b701b766797b7882 (diff) CharBrd 7: Border shadow Bisected with: bibisect-linux64-6.2 Adding Cc: to Zolnai Tamás
*** Bug 95943 has been marked as a duplicate of this bug. ***
*** Bug 119053 has been marked as a duplicate of this bug. ***
Dear Neo, 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 http://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
Bug still present in v6.4.2.2. Also, it should be noted that this bug applies to numbering as well.
Repro in Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
Also in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: f2389a70da606768a39ee599de6a5b24058734aa CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
I'm not sure why version was set to 4.2. I don't even SEE any borders in "box style cut off.odt" until bibisect-50max author Miklos Vajna on 2015-02-03 19:36:36 +0100 commit f1f6b6db730ae67a427c7974b59a5e19ab571984 xmloff: write character borders in the extension namespace for now As soon as the borders appeared, the left border wasn't seen in "box style cut off.odt", and there was a gap in the borders for comment 6's "Untitled 1.odt". I don't see any reason for the bibisect result, or for calling this a regression.
*** Bug 147846 has been marked as a duplicate of this bug. ***
Have expanded the summary to cover documented cases from bug 147846 Tested with: Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: bbec710bd25fc5da27636cde73fe4ab23c76904f CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win May also be a problem with TOC / index entries - see bug 149517
*** Bug 149517 has been marked as a duplicate of this bug. ***
Still present in Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: hu-HU (en_US.UTF8); UI: en-US Debian package version: 4:24.2.0~rc2-2 Calc: threaded But I guess this will not self-heal or fix itself and there seem to be no activity about that, so probably this will be present in all future versions, too. (Putting a space before makes the border visible, but that obviously isn't the solution.) (Well, actually, putting a zero-width space before it, using a different style actually works around the problem without visible deterioration but it's still not a solution.) My test was simply creating a character style with border and put it into a bullet list.
Additional information, based on my test of a character style with border: It seems that the border is invisible when LO thinks that the "space" before the leftmost character is the same style. Switching on Character Style Spotlight mode reveals that - when the first (leftmost) character is styled with border, - then the _bullet_ (the parts before the leftmost chartacter) is styled with same style, bordered, and thus the left border is not drawn (since the same style is before the character so the border ought to be somewhere leftwards). Other bullets are styled borderless (No Character Style) iff the first character (whatever it is, even a zero-width space) is styled borderless (No Character Style). So I believe this problem is related to the "limbo style" of the "default" lists: the bullets do not seem to have a real style, they are randomly selecting styles based on the first character, and their real visible style comes from elsewhere (the bullet list style I suppose). It is not possible to force the bullet to be a specific character style: when I try it changes then it immediately changes back.
Created attachment 192296 [details] Character style example around bullets, with and without a styled ZWS