Bug Hunting Session
Bug 121241 - MacOS: table borders aren't black but grayish ( zoom level < 150% )
Summary: MacOS: table borders aren't black but grayish ( zoom level < 150% )
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All Mac OS X (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0 target:6.2.5
Keywords: bibisected, bisected, regression
: 123248 123867 124056 124312 124547 126215 (view as bug list)
Depends on:
Blocks: regressions-buffering-GraphicData
  Show dependency treegraph
 
Reported: 2018-11-07 12:01 UTC by Telesto
Modified: 2019-07-03 15:45 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Comparison Linux and Mac (56.83 KB, image/png)
2018-11-10 12:53 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-11-07 12:01:17 UTC
Description:
MacOS: table borders aren't black but grayish

Steps to Reproduce:
1. Open Writer
2. Insert at table

Actual Results:
Grayish border

Expected Results:
Deep black


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.2.0.0.alpha1+
Build ID: 317f5f2323b8ff7948c4812faaeb0c2a3b907ce8
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-11-07_00:12:59
Locale: nl-NL (nl_NL.UTF-8); Calc: threaded
Comment 1 Xisco Faulí 2018-11-07 12:42:11 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=7034311dce663c895577267110baadbec312d491

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-09-06 18:15:02 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-09-13 08:49:35 +0200
commit	7034311dce663c895577267110baadbec312d491 (patch)
tree	8c1d712cbfb1b15dc492e6e724b6b22892914249
parent	d92b0efe58b77247e1e5292c1a989baa934df797 (diff)
Support buffering SystemDependent GraphicData (II)

Bisected with: bibisect-mac64-6.2

Adding Cc: to Armin Le Grand
Comment 2 Armin Le Grand 2018-11-08 16:46:41 UTC
Should work, see AquaSalGraphics::drawPolyLine:

    if(bPixelSnapHairline) { aPolyLine = basegfx::utils::snapPointsOfHorizontalOrVerticalEdges(aPolyLine); }

That line does the trick, and it's neither missing nor has bPixelSnapHairline changed...

@Xisco: Can you please re-check when the build including tdf#120252 is available?
Comment 3 Xisco Faulí 2018-11-09 10:25:36 UTC
(In reply to Armin Le Grand (CIB) from comment #2)
> Should work, see AquaSalGraphics::drawPolyLine:
> 
>     if(bPixelSnapHairline) { aPolyLine =
> basegfx::utils::snapPointsOfHorizontalOrVerticalEdges(aPolyLine); }
> 
> That line does the trick, and it's neither missing nor has
> bPixelSnapHairline changed...
> 
> @Xisco: Can you please re-check when the build including tdf#120252 is
> available?

Hi armin,
I can still reproduce it in

Version: 6.2.0.0.alpha1+
Build ID: 2c614b4b2537997aece7ba0aa7ecd38e55fcffaa
CPU threads: 8; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
Locale: en-US (en_ES.UTF-8); UI-Language: en-US
Calc: threaded

which already contains your commit for tdf#120252
Comment 4 Armin Le Grand 2018-11-09 18:46:55 UTC
@Xisco: Sorry, forgot: Is that mac-specific? It should not be...
Comment 5 Telesto 2018-11-09 19:36:57 UTC
(In reply to Armin Le Grand (CIB) from comment #4)
> @Xisco: Sorry, forgot: Is that mac-specific? It should not be...

Hard to say. There is something off on Windows too (horizontal borders a bit fuzzy; not as crisp as before. See bug 121026). 

The borders on the Mac looks like a table without borders
Comment 6 Xisco Faulí 2018-11-10 12:53:41 UTC
Created attachment 146522 [details]
Comparison Linux and Mac
Comment 7 Xisco Faulí 2018-11-10 12:55:02 UTC
(In reply to Armin Le Grand (CIB) from comment #4)
> @Xisco: Sorry, forgot: Is that mac-specific? It should not be...

See the image attached. BTW, it's displayed if zoom is higher than 140%
Comment 8 Telesto 2018-11-10 13:37:36 UTC
(In reply to Xisco Faulí from comment #7)
> (In reply to Armin Le Grand (CIB) from comment #4)
> > @Xisco: Sorry, forgot: Is that mac-specific? It should not be...
> 
> See the image attached. BTW, it's displayed if zoom is higher than 140%

I'm also seeing the same fuzzy horizontal borders on the screenshot (in comparison the vertical ones :-) (not sure if this relevant here, but anyway)
Comment 9 Armin Le Grand 2018-12-05 13:53:33 UTC
It's not really an error, but let me explain...

On the mac the line is shown as it is defined. It is a black line with (zoom-dependent) less than a pixel of line width, drawn using AntiAliasing.

For historical reasons we paint those Lines as one-pixel lines in LO - which makes a lot of work to force them when zooming out to not get taller than one pixel. This actually means to have some paint (and layout (!)) dependent on zoom level.

Historical reasons: When LO/AOO/StarOffice was not yet capable of painting AntiAliased at all, you had only one choice with lines - paint them or do not paint them. It could be calculated that they are less tall than one pixel, but not painting them means that they 'disappeared' at some time when zooming out - thus the decision to always paint them.

So - yes this is a bug since the mechanisms to force lines to be painted at least one pixel wide seems broken on mac.

Hard to say where and why this happens - as I said, this is a delicate and complicated mechanism...
Comment 10 Armin Le Grand 2018-12-05 14:02:26 UTC
For the other systems: As soon as a line gets more than one pixel wide (in discrete units) it *will* be painted AntiAliased and thus might get a little 'blurry' - I understand that this is unused to see, but the old hacks in LO to paint two single-pixel-lines non-AAed have to go at some point for the better.

This leads to huge problems with e.g. all types of borders. Example: If you snap them to two pixels width (real width between 1.5 and 2.49) - where do you put the line center? One up/down? One right/left? How can you match that with the added next vertical line for FrameBorders then? This leads to *hell* and is not really solvable/mainitainable in the long term.
This is the reason edge matchings of FrameBorders looked as bad as it looked in older versions. This all works much better with what we use now.

Thus I opt - I think with good arguments - to paint lines with a discrete (pixel) width of more than one now and in the future as correct as possible: AntiAliased and as close geometrically to where they are defined.

I would even opt for doing this when the lines get taller than one pixel, but - as explained above - there are historical reasons not to do that currently. But be aware that the visualization is less correct with that.
Comment 11 Armin Le Grand 2018-12-05 14:05:45 UTC
So the quesion remains - how to fix that on the mac...?
Comment 12 Alex Thurgood 2018-12-06 11:09:00 UTC
(In reply to Armin Le Grand (CIB) from comment #11)
> So the quesion remains - how to fix that on the mac...?

Hi Armin,

Will the fact that Apple has deactivated subpixel antialiasing in 10.14 (Mojave) also have an incidence on how any solution (yet to be determined) might look on Mac ? The problem is fairly acute for non-Retina displays, making everything look fuzzy, and not all users are on Macbooks.
Comment 13 Al Maloney 2019-01-02 12:06:12 UTC
For me, this problem exists in the display.
The borders print properly.

Using:
Version: 6.2.0.1
Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1
CPU threads: 4; 
OS: Mac OS X 10.12.6; 
UI render: default; 
VCL: osx; 
Locale: en-CA (en_US.UTF-8); 
UI-Language: en-US
Calc: threaded
Comment 14 cpohle 2019-02-01 12:32:53 UTC
I can repoduce this (Version: 6.2.0.3, Build-ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62, CPU-Threads: 4; BS: Mac OS X 10.14.3; UI-Render: GL; VCL: osx).

Table borders become visible at about 350 percent zoom level if anti-aliasing is active. They look fine (and are usable) with anti-aliasing disabled.
Comment 15 Joop Lanting 2019-02-09 18:37:52 UTC
Moreover: in 6.2.0.3 when trying to make borders thicker (say 0.5)
all background colours in cells change, maybe are inverted.
Pity, 6.1.2.4 was a relief after 6.1 problems.
;JOOP!
Comment 16 Joop Lanting 2019-02-09 18:42:06 UTC
One more: setting text in a table to bold can not be toggled, but
has to be undone by CMD/Z.
Both CMD/B and clicking the button above have this problem.

Is there more to come? I'll find out tomorrow.
;JOOP!
Comment 17 Joop Lanting 2019-02-10 09:46:44 UTC
I went 'back' to 6.1.5 which has no such problems.
;JOOP!
Comment 18 Alex Thurgood 2019-02-11 08:52:34 UTC
*** Bug 123248 has been marked as a duplicate of this bug. ***
Comment 19 Alex Thurgood 2019-02-11 09:00:10 UTC
This bug is particularly acute in charts where the grid and wall lines are almost invisible, even if set to black, and zooming in on the chart itself when selected isn't possible.
Comment 20 Joop Lanting 2019-03-07 13:22:46 UTC
Tried 6.2.1 :: no improvement.

About all the talking of MAC: 6.1.5 works excellent on Mojave 10.14.3 / Retina

6.2.1 is 'mud' on the same machine. So, retina is no factor.
;JOOP!
Comment 21 Xisco Faulí 2019-03-14 20:55:28 UTC
*** Bug 124056 has been marked as a duplicate of this bug. ***
Comment 22 dhina 2019-03-15 10:48:30 UTC
It also happens with shapes on Drawing and not only with Writer. If the shape has the same body color as the background, then the contour is not seen and the object looks invisible! Very annoying.

(with same behaviour related to the dispaly Zoom)

I am working with such shapes on Drawing, then I cannot work anymore with the new LibreOffice version and went back to Version 6.1.5.2 where I don't have this issue.
Comment 23 Xisco Faulí 2019-03-21 10:09:49 UTC
*** Bug 123867 has been marked as a duplicate of this bug. ***
Comment 24 Joop Lanting 2019-03-22 12:06:38 UTC
6.2.2 : still the same (borders and colours).
;JOOP!
Comment 25 Telesto 2019-03-25 10:54:37 UTC
*** Bug 124312 has been marked as a duplicate of this bug. ***
Comment 26 Telesto 2019-03-25 10:56:35 UTC
Adding CC: to Armin Le Grand
Comment 27 Alex Thurgood 2019-04-05 13:07:33 UTC
*** Bug 124547 has been marked as a duplicate of this bug. ***
Comment 28 Alex Thurgood 2019-04-05 13:23:35 UTC
This makes using Draw, for example, in the current 6.x releases, useless for technical drawings (I do a lot of patent drawings where reference lines are drawn to point out particular features of the drawing and a reference numeral given at the free end) - the lines currently all virtually disappear at normal page view zoom, or else are all transparent grey, even when they have been defined as black.

If I am actually drawing vector images with such lines, I need to be able to see the objects I am drawing.

Line widths in patent drawings are regulated by various different rules according to the corresponding patent administration. At a minimum, the line widths are generally 0,3mm, although axis lines can be even thinner e.g. 0,18mm. Being able to see and recognize them is essential to being able to use Draw as a tool to do this.

Currently, I have had to go back to LO4162 to actually be able to use Draw functionally (other macOS specific bugs linked to LO canvas refreshing and object memory management in Draw on Mac). Clearly that can not be a long term solution.
Comment 29 Telesto 2019-04-05 14:15:59 UTC
(In reply to Alex Thurgood from comment #28)
Does disabling Anti-Aliasing improve things? See Comment 14 Tools > View > Graphics Output > Anti-Aliasing  (I'm not having recent builds around; so not able to test it myself)

Offtopic 
> Currently, I have had to go back to LO4162 to actually be able to use Draw
> functionally (other macOS specific bugs linked to LO canvas refreshing and
> object memory management in Draw on Mac). 

Where should a look for these? I prefer to be in the loop :-)
Comment 30 Joop Lanting 2019-04-18 17:35:01 UTC
6.2.3 : still the same
;JOOP!
Comment 31 Xisco Faulí 2019-05-06 15:48:31 UTC
Still reproducible in

Version: 6.3.0.0.alpha0+
Build ID: e575a5e8f89beb3ce1df5a1d83edc0f9d1d8ac43
CPU threads: 8; OS: Mac OS X 10.14.2; UI render: default; VCL: osx; 
Locale: en-US (en_ES.UTF-8); UI-Language: en-US
Calc: threaded

After bubli's fixes for bug 120585 and bug 120797.

@Bubli, another one from 7034311dce663c895577267110baadbec312d491, unfortunately only reproducible on mac...
Comment 32 Joop Lanting 2019-05-25 09:56:55 UTC
6.2.4 : still the same
;JOOP!
Comment 33 Xisco Faulí 2019-05-31 10:29:47 UTC
Patch in gerrit: https://gerrit.libreoffice.org/#/c/73249/
Comment 34 Commit Notification 2019-05-31 12:33:07 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/16091ff88aaab9ba9103c4e369bf79b97f431f40%5E%21

tdf#125506 tdf#121241: No need to transform to DeviceCoordinates

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 35 Commit Notification 2019-06-04 08:22:44 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/b6a3d0566628e2d8416708d0410193435a3b8e53%5E%21

tdf#125506 tdf#121241: only use rObjectToDevice if needed

It will be available in 6.2.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 36 Xisco Faulí 2019-07-03 15:45:58 UTC
*** Bug 126215 has been marked as a duplicate of this bug. ***