Description: The drop-down graphic pane for selecting the cell border style presents incorrect graphic illustrations of the anticipated results. I'm also convinced there used to be a much thinner "default" single-line border. The help page associated with the cell format [F1] Help function doesn't exist Steps to Reproduce: Refer to the attached demonstration file. It may help to zoom the sheet Actual Results: Borders are inconsistent with the grsphic representations. Also, I'm convinced there was a "default" single outline defined as soon as an outline was selected. Now it's blank until the characteristics have been "selected" but it was much thinner than the current Outset option which presents as the thinnest line. Expected Results: Consistency. I suspect previous work on the outline function has erroneously left the programmers' experiments as the currently delivered defaults. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.7.2 (x64) / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 184198 [details] Simple .ods with examples
I also agree that the current default width is too thick. Instead of 0.75pt we could go with 0.5pt or even 0.25pt (which is not available in the dropdown). The previews are also thicker than what you actually get when applying the border. IIRC using the hairline (0.05pt) caused XLSX export issues, making the line appear dashed in MS Excel. Here's a related request: bug 144141.
(In reply to Colin from comment #0) > The drop-down graphic pane for selecting the cell border style presents > incorrect graphic illustrations of the anticipated results. Don't get this. Could you add a screenshot please. (In reply to Rafael Lima from comment #2) > I also agree that the current default width is too thick. This has been discussed and changed recently in bug 48622 and bug 99027. The mentioned ticket to remember the last user choice is a good solution.
(In reply to Heiko Tietze from comment #3) > (In reply to Colin from comment #0) > > The drop-down graphic pane for selecting the cell border style presents > > incorrect graphic illustrations of the anticipated results. > > Don't get this. Could you add a screenshot please. > Perhaps look at the screenshot of the drop down graphic pane included as a graphic in attachment 184198 [details]. I appreciate that it was elongated to permit alignment with the adjacent outlined cells but it was embedded over columns A & B which precede column C where those cells have actually been defined with the outlines inconclusively depicted in the screenshot. Short version - Wake up HT😏
(In reply to Colin from comment #4) > Perhaps look at the screenshot ... in attachment 184198 [details] I try to avoid downloading files and asked therefore for a screenshot. But you are right with the example file, it allows to play with the settings. (In reply to Colin from comment #4) > Short version - Wake up HT😏 Stay nice :-p
Another observation; If you zoom the sheet to its max and then take a good look at the manner in which the borders are created, you'll notice that they don't form symmetrical border lines. Where an outline is two components, they are in reality just the pair of lower boundary lines which have been "cut and pasted" in the same orientation to the top boundary and "flipped right" for the two side boundaries. They're so "out of sync" that they don't even properly recreate a "dropped shadow". My experience of manually creating borders is too limited to know whether or not the system will make the correct symmetry. Compare the borders with any decorative picture frame to appreciate what I'm inferring.
The line style needs to be more or less as it is for compatibility with MSO [see 1,2]. In fact, the lines are different, at least from the stored values (read from the ODF data). dotted dashed double "0.009cm 0.009cm 0.009cm" double "0.026cm 0.026cm 0.002cm" double "0.007cm 0.007cm 0.014cm" double "0.026cm 0.004cm 0.053cm" double "0cm 0.026cm 0.026cm" double "0.014cm 0.007cm 0.007cm" double "0.053cm 0.004cm 0.026cm" ridge groove outset inset From [3]: "The first value specifies the width of the inner line, The second value specifies the distance between the two lines, and The third value specifies the width of the outer line." If you change the background color it becomes a bit more clear for engraved/embossed. But the preview of the drodown is definitely not our best. Need to look deeper into the code how it is drawn from SvtLineListBox::UpdatePreview(). [1] editeng/source/items/borderline.cxx [2] svtools/source/control/ctrlbox.cxx [3] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#property-style_border-line-width
(In reply to Heiko Tietze from comment #7) > double "0.009cm 0.009cm 0.009cm" > double "0.026cm 0.026cm 0.002cm" > double "0.007cm 0.007cm 0.014cm" > double "0.026cm 0.004cm 0.053cm" > double "0cm 0.026cm 0.026cm" > double "0.014cm 0.007cm 0.007cm" > double "0.053cm 0.004cm 0.026cm" > From [3]: "The first value specifies the width of the inner line, The second > value specifies the distance between the two lines, and The third value > specifies the width of the outer line." > The two I pushed out are the worst offenders in my comment #6 because the symetry requires them to be flipped both vertically and horizontally to ensure the different line weights actually "mitre" together properly. But anywhere the line weights (1st & 3rd parameters) are not identical will still not "bind" the corners correctly. The current practice matches bottom & left with continuity of weight and top & right but then the vertices at bottom & right and top & left flip the line weight connections. It's not so significant with lower font weight cells but larger cells, merged cells and zoomed documents clearly demonstrate the anomaly.
Created attachment 184271 [details] Screen Image demonstrating lack of symetry
Looks like we cannot achieve symmetry and a large number of options. Regina, what do you think? The initial bug report was about the preview in the drop down. Valid issue => NEW The help/documentation aspect would be better handled in a different topic (as a rule of thumb, submitting a patch should resolve a ticket - and help related patches rarely include C++ code).
(In reply to Heiko Tietze from comment #10) > Looks like we cannot achieve symmetry and a large number of options. Regina, > what do you think? > > The initial bug report was about the preview in the drop down. Valid issue > => NEW > Heiko, My bad, I noticed the symetry issue when I put my spectacles back on. Do you need me to raise another ticket for that or is it something that will naturally follow (or be discounted) from Regina's thoughts?
(In reply to Colin from comment #11) > Do you need me to raise another ticket... The lines are defined as in comment 7 and changing this might achieve symmetry. The dropdown "preview" is another topic and could be handled in a different ticket. But let's wait for further input.
(In reply to Heiko Tietze from comment #12) > (In reply to Colin from comment #11) > > Do you need me to raise another ticket... > > The lines are defined as in comment 7 and changing this might achieve > symmetry. Looking at the pane for defining the borders in "Format Cells" I only see "Padding" and a "Synchronise" tick box - neither of which appear to regulate the symmetry. Are the parameters you referred to available for the user to modify? Also, If I am able to change the parameters does that imply I would break something if I then exported it to Excel or simply that it wouldn't retain the symmetry? Should I be raising these questions in the help forum?
(In reply to Colin from comment #13) > Are the parameters you referred to available for the user to modify? No, but you could hack the ODF document. > Also, If I am able to change the parameters does that imply I would break > something if I then exported it to Excel or simply that it wouldn't retain > the symmetry? I'm afraid it would be the consequence (if there is some kind of a standard). > Should I be raising these questions in the help forum? Guess it's rather a developer question.
(In reply to Heiko Tietze from comment #14) > (In reply to Colin from comment #13) Thanks
After upgrading from LO 7.0 to 7.4 I have realized that the default thickness of Calc border lines is much higher. Attaching a screenshot in which the expected case is obtained by manually selecting the "hairline" thickness.
Created attachment 185622 [details] borderline expections vs reality