Created attachment 180261 [details] Border options available in Excel Excel offers 3 options for border thickness when it comes to solid borders (see first attachment showing these options). I'll call them "Thin", "Medium" and "Thick", since MS does not provide names for them in the user interface. The way LO Calc import these borders is causing a bit of inconsistency, because our import is making the borders look much thicker than they should. For example, if you apply these borders in Excel, save the XLSX document and open it in LO Calc they will appear with excessive border weight. Below I'll attach more files showing the problem, as well as a sample XLSX file. I believe the way we convert border thickness needs to be improved. Or maybe the way we draw these borders in the screen. This is because in Excel, if you zoom in/out the border thickness does not change, whereas in LO Calc zooming affects the thickness of the border drawn in the screen. System info: Version: 7.3.3.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.3.3~rc2-0ubuntu0.21.10.1~lo1 Calc: threaded
Created attachment 180262 [details] Sample XLSX file used in the screenshots
Created attachment 180263 [details] Screenshot of the file opened in Excel at 200% zoom
Created attachment 180264 [details] Screenshot of the file opened in LO Calc at 200% zoom
Created attachment 180586 [details] Sample XLSX in MSO and LO Seems so. Bug 48622 introduced predefined thickness, but it doesn't look like MSO.
Created attachment 180587 [details] Sample XLSX in MSO and LO modified Thin from MSO could be Very Thin, Medium could be Thin, Thick could be Medium.
Created attachment 186625 [details] How LO7.6 renders the Excel styles "hair", "thin", "medium", "thick" The screenshot compares rendering in Excel with rendering in LO 7.6. The screenshot was taken with 180% zoom on a display with 120dpi.
Dear Rafael Lima, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug