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
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
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?
(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
@Xisco: Sorry, forgot: Is that mac-specific? It should not be...
(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
Created attachment 146522 [details] Comparison Linux and Mac
(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%
(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)
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...
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.
So the quesion remains - how to fix that on the mac...?
(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.
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
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.
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!
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!
I went 'back' to 6.1.5 which has no such problems. ;JOOP!
*** Bug 123248 has been marked as a duplicate of this bug. ***
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.
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!
*** Bug 124056 has been marked as a duplicate of this bug. ***
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.
*** Bug 123867 has been marked as a duplicate of this bug. ***
6.2.2 : still the same (borders and colours). ;JOOP!
*** Bug 124312 has been marked as a duplicate of this bug. ***
Adding CC: to Armin Le Grand
*** Bug 124547 has been marked as a duplicate of this bug. ***
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.
(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 :-)
6.2.3 : still the same ;JOOP!
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...
6.2.4 : still the same ;JOOP!
Patch in gerrit: https://gerrit.libreoffice.org/#/c/73249/
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.
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.
*** Bug 126215 has been marked as a duplicate of this bug. ***