Description: i selected a part of an image in mspaint, copied it, and pasted it into the odt Document. The image then shows a thin grey outline at the right, and at the bottom of the pasted image. In printpreview there is no line. if i paste again the image itself inside LO-Writer the grey line at the bottom disappears. Sometimes it's a line at the right, sometimes it's a line at the bottom. Sometimes both. If i make a new line inside the document - the line disapears. if i make another line, the line appears again. Sometimes that is not happening. Seems that it has something to do with the position. Steps to Reproduce: 1. make a screenshot and paste it into mspaint 2. select a part of the image and copy it 3. paste into writer Actual Results: Thin grey line, at the right and at the bottom. But not always. Expected Results: No thin grey line Reproducible: Sometimes User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.0.0.1 (x64) Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd CPU-Threads: 4; BS: Windows 6.3 Build 9600; UI-Render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL
Created attachment 163126 [details] ODT-File - Grey Line at the right and bottom of image
Occurs also in 7.0.0.1 RC1
From my perspective this is just non-printing visual aid "Text Boundaries" and will vanish if View -> [ ] Text Boundaries will be deactivated. Would rate that being not a bug
I agree partly. The behaviour occurs sometimes, and sometimes not. But you are right, that it disappears if View -> [ ] Text Boundaries will be deactivated.
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
- Started 7.0.0.1 RC 1 in safe mode. resetted user data. Restart, normal version - Error still occurs. Most of the time - Started 7.0.0.1 RC 1 in safe mode. problem does not occur - Restart, normal version. Error still occurs. Most of the time
Created attachment 163221 [details] ODT-File - Grey Line at the right and bottom of image by Inserting and Moving
Created attachment 163227 [details] ODT-File - Grey Line at the right and bottom of image by Inserting and Moving ODT-File, better than JPG
I confirm it with Version: 7.0.0.0.beta2 (x64) Build ID: 1c213561a365b5666167321de68c9977500c9612 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL but no with Version: 6.4.5.2 (x64) Build-ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6 CPU-Threads: 4; BS: Windows 10.0 Build 19041; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
By bibisection I have discovered the first commit with this bug. https://git.libreoffice.org/core/+/a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db But it is not what we are searching. Instert the image, click by second button on it, click ANCHOR > AS CHARACTER. After this it works same like in the old version 6.4.5.2. By bisecting I have discovered only default setting on paste of the image. I also checked this in Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 and when i set anchor "As character" then there is gray color around the image. When I set "To character" then there is no grey lines. So there is still regression and bibisectRequest.
I have tested anchor seted "To character". In old versions is no grey line, in the new there is. Report from bisecting: 332a8389db98b1e2f1d57b6de7b90c61c5224ebc is the first bad commit commit 332a8389db98b1e2f1d57b6de7b90c61c5224ebc Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Dec 12 21:31:37 2017 -0800 source da05b60cdb72d301c6b16c8cb31135f46f4ed2c0 I am adding Armin Le Grand to CC list.
And also I seted priority to minor i thing it more corespond with wiki https://wiki.documentfoundation.org/QA/BugTriage#Step_8:_Prioritize_Bug (Maybe it should be trivial).
*** Bug 142275 has been marked as a duplicate of this bug. ***
*** Bug 138560 has been marked as a duplicate of this bug. ***
FYI: I added some useful information to Bug #138560 which is marked as a duplicate of this one: - screenshots showing how the lines appear/disappear, depending on the zoom factor - work-around to hide the unwanted lines
Dear Udo, 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
Grey lines at right and bottom of inserted image not present in version 7.6.4.1 Bug seems to have been fixed.
Bug not present in version 7.6.4.1 No lines showing to right and bottom of inserted image as they did in version 7.5.3
Yes, even with View - Boundaries selected, there are no lines Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a9ad36ae46ff76c0d59b0d170314fdd3a9ee5d35 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
*** Bug 159424 has been marked as a duplicate of this bug. ***
Setting back to NEW - fresh duplicate report has attachment 192232 [details], which still shows this issue!
Using my own document as a test, I confirm the 6.0 bibisect from comment 11. In bibisect-linux-64-6.0, I got bibisect commit 75a5bb5fe97dc758e0a97b76c88f97b23c7dfd6b is the first bad commit one of this clump of commits: source d74b26b41bfea3ba7a1834953b2bfe9b7ff0d70f source 1059e234f4b3b3f6b770b2e4d973923e54e7045b source 7d391f9a563041aae416c7017dcec36bbf4dfb2c source 4cee8018792c732aac638bd82c754ade915a4db9 source c82cb453eb56fb37ad36cff6becde9d753eb829d source da05b60cdb72d301c6b16c8cb31135f46f4ed2c0 // tagged in comment 11 source 51ee0c5ba6b0ffcd4b12e652de48e3f775cccc7d The example file I was using had some false positives in 5.4, where the header/footer line was occasionally leaving an image-wide artefact above or below the image. I don't think Armin's commit is truly a regression. I think it is finally showing (some of) the text boundaries that were intended to be shown.
Looking at the output of sw/source/core/layout/paintfrm.cxx's SwSubsRects::PaintSubsidiary calls DrawRect on all four borders, so I don't see anything wrong. I was using an example file where I could see only two lines when wrapped AT_CHAR, and all four lines when wrapped AS_CHAR. Swapping between the two anchor types left everything else identical in the file, and the last drawRect output I saw drew the exact same coordinates in both cases, but visually the AT_CHAR version was missing the top and left border. This will require a graphics layout expert.
Created attachment 193343 [details] 134869_missingTextBoundaries.odt: toggle between as-character and at-character - the file used in comment 23 Note that in 24.8, "show formatting marks" also needs to be turned on to see text boundaries around images (bug 131253).