<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - MacOS: table borders aren't black but grayish ( zoom level < 150% )" href="https://bugs.documentfoundation.org/show_bug.cgi?id=121241#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - MacOS: table borders aren't black but grayish ( zoom level < 150% )" href="https://bugs.documentfoundation.org/show_bug.cgi?id=121241">bug 121241</a> from <a class="email" href="mailto:Armin.Le.Grand@me.com" title="Armin Le Grand (CIB) <Armin.Le.Grand@me.com>"> Armin Le Grand (CIB)</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>