Description: Horizontal table borders appear slightly fatter compared to vertical lines Steps to Reproduce: 1. Insert a table (default style) Actual Results: Horizontal table borders appear slightly fatter compared to vertical lines Expected Results: Same borders Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.2.0.0.alpha1+ Build ID: cb7500ddb8de6c41fca84a0009ffe22240bb1845 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-29_03:24:02 Locale: nl-NL (nl_NL); Calc: C
Created attachment 146521 [details] How it looks on linux gtk3 On linux ( gtk3 ) it looks better on master than on 6.1.3.2
(In reply to Xisco Faulí from comment #1) > Created attachment 146521 [details] > How it looks on linux gtk3 > > On linux ( gtk3 ) it looks better on master than on 6.1.3.2 Attachment 146522 [details] does shows the issue
Bug confirmed Version: 6.3.0.0.alpha0+ Build ID: 8a02a1d329c43df6de383a7b0cf8ac14247b18c9 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-17_20:48:16 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 147129 [details] Look different but actually not I insert a table and take screenshot. After I zoom in to 600%, the bug really exists. But when I go back to Libre office writer and directly zoom in to 600%, the borders are having same width.
Set to NEW because of comment 3
Created attachment 147156 [details] Bibisect log Bisected to author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-10-25 10:06:05 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-10-25 12:43:55 +0200 commit 313392119522c21a6ecd14403d6f92c948149df7 (patch) tree fbd1a112a41f83d34c6bb6ea79eeccf73dba3e7b parent 8dec85a3b3f4cbd46b03f707458347a25cc22c15 (diff) Reorganize FrameBorderPrimitive creation (II) Step5: Move the view-dependent decomposition from BorderLinePrimitive2D to SdrFrameBorderPrimitive2D. https://cgit.freedesktop.org/libreoffice/core/commit/?id=313392119522c21a6ecd14403d6f92c948149df7
Adding CC: to Armin Le Grand
Sorry for the spam
Personally I see the line drawing better in master than in 6.1, specially when zooming. To me it's rathen an improvement than a bug... Adding the UX team to know their opinion...
(In reply to Xisco Faulí from comment #9) > Adding the UX team to know their opinion... It depends on the render engine (both OS and LibO). Tools > View > Graphics Output > Anti-Aliasing has a significant impact on the lines.IIRC, Armin changed the subpixel calculation, let's see what he says.
@Xisco Any change that the fix for bug 121241 could be used here too? BTW the issue is limited to Anti-Aliasing (comment 10)
Created attachment 151867 [details] how it looks after the patch
Created attachment 151868 [details] how it looks before the patch
it seems fine to me. Please reopen it if you disagree.
Sorry, reopening 1. This report is about Windows, not MacOS. (Didn't check MacOS) 2. Behavior is still the same. Borders are - with Anti-Aliasing - enabled rather fuzzy/fat. This didn't exist in previous versions with Anti-Aliasing enabled. Not sure how I can illustrate properly. Anti-Aliasing is an improvement at certain zoom-levels but not in general, IMHO. Rather hard to give an example, because of the multiple influences at play (zoomlevel, border size, screen used) A border of 2,0 pt is crisp without Anti-Aliasing and slightly fuzzy with Anti-Anti-Aliasing on my non-HiDPI screen. At zoom level between 50-200. 1. Open Writer 2. Insert a table with 2.0 pt line width at zoom 175 or something like that 3. Open Tools -> options 4. Position the dialog so that you can see the table 5. View -> Uncheck Use anti-aliasing & press apply 6. Check & anti-aliasing & press apply (and notice the difference) The (only) advantage of Anti-Aliasing is it masking drawing issues at corners (horizontal/vertical lines don't always exactly match on screen; again depending on zoomlevels/ border line thickness)
Then it's not fixed, my commit changed mac related code
@Telesto, could you please attach a screenshot ? the one from comment 2 is on macos. OTOH, this issue was confirmed in comment 3 with gtk3, which is incorrect...
Created attachment 151869 [details] Screencast An attempt to show to difference.. Not to easy to record though
Version: 7.0.0.0.alpha0+ (x64) Build ID: 7ae9c9572ccac55c0926b8a9779bb63c4236291c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
AA is used for CellBorders using resolution-dependent primitive decompositions starting from a fixed liniewidth, but that is the same for all systems. Thus this should be mostly the same, of course depending on graphic backend for how it does AA in the last system-dependent step. I can check if I find something on windows, but it may just be the backend. I would not propose to change the fixed linewidth from when to start using AA e.g. system-dependent.
Those small system- and backend-related AA-relicts are unavoidable. To fix we would need to use an internal software-renderer, that would guarantee to getthe same AAing on all systems. This would be slow and not a good choice.