When I change the scale of the document there are several artifacts with cells borders. Borders are going through next cell border.
Steps to Reproduce:
1. Open this document https://yadi.sk/d/9RC1JcPY3S2kHa
2. Change the scale.
On this picture, you can see that lines a go through neighbor cell borders https://yadi.sk/i/YkDfRJFY3SHFbv
The same result exists in a printing preview dialog.
Check the scaling algorithm. I think now it's not properly calculated the end of current cell or border length.
User Profile Reset: Yes
It happens in a new release.
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.140 Chrome/64.0.3282.140 Safari/537.36
Nothing happens when I click on the Download link. Could you please attache the test file to this bug report. I do see the preview of the screenshot.
Created attachment 139771 [details]
(In reply to Kevin Suo from comment #1)
> Nothing happens when I click on the Download link. Could you please attache
> the test file to this bug report. I do see the preview of the screenshot.
Attached. Check this.
(In reply to Ilya Zubakin from comment #3)
I reproduce this on 126.96.36.199 release.
CPU 线程：4; 操作系统：Linux 4.14; UI 渲染：默认; VCL: gtk2;
区域语言：zh-CN (zh_CN.UTF-8); Calc: group
It works in:
Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
CPU threads: 4; OS: Linux 4.14; UI render: default; VCL: gtk3;
Locale: zh-CN (zh_CN.UTF-8); Calc: group
I also noticed that, if I set the zoom level below 280%, there are artifacts. But if the zoom level is 310% or above, the artifacts to the right of column CQ are gone, but artifacts on column CX remain.
I also did a real printing-out of the page, and find that the borders are OK, without artifacts.
I am adding Armin Le Grand to cc list, as he has worked on a series of improvements on the cell borders.
@Armin Le Grand: If you need me to to some bibisects, please let me know.
I can't reproduce:
Version: 188.8.131.52 (x64)
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 4; OS: Windows 10.0; UI render: GL;
Locale: es-ES (es_ES); Calc: CL
With or without OpenGL enable.
Steps to reproduce:
1. Open attached document
2. Zoom to 280%
3. Check 'Код' border as displayed here: https://yadi.sk/i/YkDfRJFY3SHFbv
Regression introduced by:
author Armin Le Grand <Armin.Le.Grand@cib.de> 2017-07-21 17:34:40 +0200
committer Armin Le Grand <Armin.Le.Grand@cib.de> 2017-07-28 17:51:56 +0200
commit bc47d7138a8d8dd239831a38bb2eca9db13addb6 (patch)
parent e32c12a444e5bd0c6735db8e8008340c29a7e25e (diff)
borderline: first versionj with line end adaptions
Added usage of defined extensions to the BorderLinePrimitive,
also added a first version to detect all cuts with adjacent
borders and produce the correct extensions, for single and
double lines. Not completely happy with it, but a first
Bisected with: bibisect-linux64-6.0
Adding Cc: to Armin Le Grand
I can see it now with:
Version: 184.108.40.206 (x64)
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Windows 10.0; UI render: default;
Locale: es-ES (es_ES); Calc: CL
More or less gone with latest changes in master. Only slightly too ong lines when far zoomed out, as result of AA paint, but not really bad from my POV. Same rendering when save as PDF and view with a PDF renderer, so not sure if it has to do with LO
*** Bug 121036 has been marked as a duplicate of this bug. ***
Looks fixed with
Build ID: libreoffice-220.127.116.11-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: en-US (en_US.UTF-8); UI-Language: en-US
and can be closed?