Created attachment 171780 [details] Writer-Dokument mit der Tabelle Ich möchte die erste Tabellenspalte und später auch die oberste Tabellenzeile mit einer einfachen Tabellenlinie von den anderen Zellen abgrenzen. Ausgangspunkt ist eine Tabelle ohne Trennlinien, bei der sowohl in den Tabellen- als auch in den Absatzeigenschaften der Innenabstand der Umrandung gleich Null ist. (vgl. beigefügte Writer-Datei) Dazu markiere ich die erste Spalte und klicke den Button "rechte Innenlinie" (vgl. auch meine Post bei Ask LibreOffice mit Screenshot). Mit dem Einfügen der Trennlinie wird unverständlicherweise gleichzeitig auch die Zellenhöhe vergrößert. Bei den Tabelleneigenschaften wurde dazu der Innenabstand von 0,0 auf 0,1cm erhöht. Das habe ich nicht bestellt und mache es anschließend wieder rückgängig. Dabei wandert die Innenlinie ganz nach rechts neben die vierte Spalte. Die Trennlinie neben der ersten Spalte ist jetzt verschwunden. Auch das ist für mich nicht nachvollziehbar. Ähnliches passiert, wenn ich unter der ersten Tabellenzeile eine Trennlinie einzeichnen möchte. Bis zur Version 7.1.2 konnte ich derartige Trennlinien ohne eine Erhöhung der Zellenhöhe nach einer Markierung der abzugrenzenden Tabellenzellen über die Tabelleneigenschaften/Umrandung durch Anklicken der gewünschten Linien erzeugen. Mit der Version 7.1.3 funktioniert auch das nicht mehr, die Trennlinie wird jetzt stets gleich am äußersten Rand der Tabelle gezeichnet und die Zellenhöhe wird ebenfalls erhöht. Wie kann man mit der Version 7.1.3 Trennlinien zwischen Spalten oder Zeilen einfügen, ohne dass dabei die Zellenhöhe erhöht wird und sich damit sämtlichen Seitenumbrüche im Dokument verschieben? Vielen Dank.
English translation: I would like to separate the first table column and later also the top row from the other cells with a simple table line. The starting point is a table without dividing lines, in which the padding of the border is zero in both the table and the paragraph properties. (see attached writer file) To do this, I mark the first column and click the "right inner line" button (see also my screenshots in my post in Ask-LibreOffice). Incomprehensibly, when the dividing line is inserted, the cell height is increased at the same time. In the table properties, the inner distance has been increased from 0.0 to 0.1 cm. I didn't order that and then I'll cancel it. The inner line moves to the far right next to the fourth column. The dividing line next to the first column has now disappeared. That is also incomprehensible to me. Something similar happens when I want to draw a dividing line under the first line of the table. Up to version 7.1.2 I was able to create such dividing lines without increasing the cell height after marking the table cells to be delimited via the table properties / border by clicking on the desired lines. This no longer works with version 7.1.3 either, the dividing line is now always drawn at the very edge of the table and the cell height is also increased. How can you insert separating lines between columns or rows with version 7.1.3 without increasing the cell height and thereby shifting all page breaks in the document?
Created attachment 171781 [details] Screenshots of the activities and results Screenshots of the activities and results
Like https://bugs.documentfoundation.org/show_bug.cgi?id=139018
Unlike https://bugs.documentfoundation.org/show_bug.cgi?id=139018 In the bug 139018 (see screencast in the belonging bugreport) the right and left borders are set to neutral and not to invisible as should be done to get the desired result. So bug 139018 might not be a bug. Due to the bug described here, it is impossible to set internal table lines without getting the cell-sizes increased (by unwanted padding increase) and internal table lines are moved to the borders of the table without the request of the user.
Let's try with steps, that are usual way to report (correct if wrong): 1. open attachment 171780 [details] 2. select 1st column AAA 3a. Set right border only via Borders icon in toolbar, OK - see that padding increased to 0,10 - NOK 3b. Set right border via Table Borders /Properties, as in screenshot - line is not after selected 1st but 4th column 3c. Set middle border via Table Borders /Properties - line is after selected 1st column as needed 4a. undo, see that padding is gone - OK 4b. after 3. do Set no borders, see that padding remains 4c. see that padding is 0,10 with column AAA selected, but 0 with no column selected, but with cursor in cell A1 - NOK Note: good you prepared sample, just better to insert screenshot with steps there, to be easier to see. Not very important. Not sure if 3a is a bug, probably it will not be and was discussed somewhere, something in bug 106926. 4c doesn't seem proper to me, again it should be searched. I guess this report is about 3b for which I'm not sure if a bug, because 3c gives intended result. But seems like there was a change in LO 7.2+ and in 7.1. Note: bug 142166 is related or same.
Thank you timor. Acccording to your suggestions i describe my steps to reproduce: 1. Open attachment 171780 [details] 2. Open the table properties and see that the padding is 0.0cm, 3. Close the table properties 4. Select 1st column AAA 5. Set right border via Borders icon in toolbar 5a. See that the cell heights were increased and the line is right to column AAA 5b. Open the table properties and see that the padding now is 0.1cm 5c. This is NOT OK, see my remark below 6. In the opened table properties set the padding back to 0.0cm (do nothing more here) 7. Close the table properties with OK 8. See that the vertical line moved from AAA to the right edge of the table 8a. This is NOT OK, the line-position was not changed in the table properties before. Remark: Up to Writer 7.1.2 it was possible to mark the 1st column AAA, then open the table properties and set the right border (always related to the selected cells) without increasing any padding.
Bibisect in 7.2+ Linux, change for 3b. from Comment 5 and for 8. from Comment 6 was: author Caolán McNamara <caolanm@redhat.com> 2021-03-12 12:57:57 +0000 committer Caolán McNamara <caolanm@redhat.com> 2021-03-12 17:17:35 +0100 commit 6db71f70a3b200d4074f6cda8ce445e9861d3296 (patch) tree 533079dfe5e83a2e5034ae8c1bb51ab7e94bcdd9 parent ce69ab8d61975d5d49142469115798b5b3688a63 (diff) tdf#140977 drop possible table-cursor before setting the new one I guess this can be called a regression, because selection (like a column) has no effect anymore in applying User-defined border via Table Borders /Properties. Left border is now absolute, middle border marks all inside vertical borders, and right border is also absolute. Not that new behavior is quite illogical, rather it's different (or I'm not aware where it's documented), but there are also other reports. In bug 139018 was wrongly added example, which is this bug. Steps: 1. open attachment 171780 [details] 2. set all borders 3. mark column BBB 4. via Table Borders /Properties remove horizontal borders Expected: only marked borders are removed, as in screencast attachment 171481 [details] Experienced: all horizontal borders are removed, as in screencast attachment 171482 [details] Bug 142166 also sounds the same: "Change borders for selected cells will change borders in all table". Apart from regression, there's a question why border adds padding. I don't see it that is changed, so I don't confirm previous remark.
Hello Timur, you wrote "Apart from regression, there's a question why border adds padding. I don't see it that is changed, so I don't confirm previous remark." Up to Writer 7.1.2 the behaviour was: a.) Adding a line using the Borders-icon in the toolbar added a padding without request. Already worse up to 7.1.2. b.) Adding a line by selecting the appropriate cells, opening the table properties and switching the lines on/off worked without adding unwanted paddings. With the current behaviour of 7.1.3 it is no more possible to set internal lines in tables without additional padding. So you get increased table sizes disordering nearly all page-breaks the document. Really worse. At least for me and other users with size-optimized tables.
*** Bug 142166 has been marked as a duplicate of this bug. ***
In 7.1.2: line formating in writer-tables work fine. 7.1.3: formating one line changes all lines in the table.
Let's add Caolán to CC, based on comment 7.
I'll take this for the regression, leaving aside the preexisting behaviour described in comment #1 para 2
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4d52d2bc81f9d27472fe368785912a530489d046 tdf#142165 restore a SwShellTableCursor if the orig selection described that It will be available in 7.2.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/7cfae0ade31a5469331f5b0288e22aed6ec2fcc1 tdf#142165 restore a SwShellTableCursor if the orig selection described that It will be available in 7.1.4. 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.
I don't see this as fixed. 72 Linux repo is at source b238522ca121ca8f863fe4d3394ade088a65ad01 so it should include the commit, or is build wrong because Help-About points to 8 days old db35b9086476259fa2c047f2e4dfe7862d026530.
I set Verified for borders. (previous message was my bad). Thanks! Note that it takes 3 clicks to remove, there's documentation bug for that.
*** Bug 142386 has been marked as a duplicate of this bug. ***
Unexpected and inconsistent adding of padding (define lines with the borders-icon in toolbar [+0,1mm] vs. using the table-properties [+0,05cm]) remains in version 7.1.4.2.
Rule of thumb is one issue per bug. Here it was borders and it's resolved so I set back Fixed, do not change. For padding, you may search existing closed and open bugs for similar issue and if not found report new.
Before reporting please see bug 106926 as indicated in comment 5.
@Timur: Caolan wrote in comment #12: "I'll take this for the regression, leaving aside the preexisting behaviour described in comment #1 para 2". Comment #1 para 2 concerns lines and adjoining padding. So reopening the bug should be right, because with the bugfix the padding was affected also.
@Timur: bug 106926 states: "Padding and borders are independent properties" So changing table-lines shall not affect padding as is done with the bugfix state now, neither via toolbar-botton nor via table-properties.
@Timur & all: The padding-bug already was reported in 2015 (bug 93975) but remains obstructing users. So why reporting a new bug with new inconsistencies (Tooolbar-botton vs. table properties) you may see as conflicting with your thumb-rule?
This bug remains fixed and no need to comment further, you may add comment in bug 93975 of you can clarify more, good to have padding explained there.
*** Bug 142850 has been marked as a duplicate of this bug. ***
Seems that this is NOK is 7.1.4, cannot see why, because OK in 7.2+.
(In reply to Timur from comment #27) > Seems that this is NOK is 7.1.4, cannot see why, because OK in 7.2+. will be fixed in bug 142721
Created attachment 172988 [details] confirm unfixed problem
Created attachment 172989 [details] confirm unfixed problem
Please have a look at the files named "confirm unfixed problem". By playing around with the cell's (top) borders of the cells with green text, either trying to add borders or remove them, in case there aren't any, the bug should become visible. It just seems inpossible to add or remove the top border of the left cell or the right one or of both cells with green text, neither in the upper line nor several lines below, without borders of other cells getting randomly removed or added. It still works correctly in version 7.0.6, but not in 7.1.3, 7.1.4.2 nor in the already available 7.2.0.0.a.
kubbugrep, it's good that we test resolved bugs, but you didn't show this was not fixed. What you wrote is too general "play around"...needed are exact steps. You attached ODT and DOCX, but DOCX is usually another bug. So best to download fresh daily master LO from https://dev-builds.libreoffice.org/daily/master/current.html that installs separately to working LO. The other day it went from 7.2+ to 7.2+. If you reproduce bug, please write exact steps in new report and connect via See Also.
Note that fresh 7.2.0 beta is also good for testing, one you already used.
Timur, thanks for your comment. I wrote "play around" because it really doesn't matter whether you add or remove the border line on the top of the specified cells in one of the attached files (odt or docx). 1. Open file 2. look for first cell with text "occaecati cupiditate" in green colour 3. select that cell 4. open "frames" tab of the "table properties" window opened via the context menu 5. here you will see first error in the "user defined" area: the left border line is missing 6. remove top border line by clicking twice on it in the "user defined" area and close that settings windows with ok 7. watch several border lines of some other cells being removed as well Alternatively you can confirm the problem with the above steps for the cell with text "molestias excepturi sint \n dicta sunt explicabo" also in green. There is one difference in step 6 since this cell doesn't have any top border line yet. Hence you have to add one in the already above mentioned "frames" tab of the "table properties" window opened via the context menu, but with only one click on the respecting place in the "user defined" area. Both files were provided just for convenience, to show, that it doesn't work, no matter of the format and to make it easier to confirm that this is a clearly bug of the program rather than a problem with the file, since for the latter one should expect similiar problems by opening the docx file with word. Whether any of the persons trying to resolve this bug is making use of the information provided is completely up to that person. I can just try to make it easier by providing as much and as useful information as possible.
With the download links you provided users can download the daily master of version 7.3, which doesn't even have an official release schedule yet: https://wiki.documentfoundation.org/ReleasePlan/7.3 For users it would be much more interesting, whether this is going to be fixed ni the 7.1 branch or whether users will have to wait another two months until the release of version 7.2. in mid/late August. Anyway, the current status "RESOLVED FIXED" is definitely wrong, since there is no non-alpha or non-beta version available with this bug resolved. That also means there simply is _no_ version for people other than developers and those people who want to just have a look at alpha's or beta's.
I don't reproduce. You may record a screencast, but be sure to show Help-About in the beginning. Fixed is proper status of this one, unless someone else in CC reproduces.
I can confirm the bug described with the steps 6 and 7 of comment 34 using Writer 7.1.4.2 with the odt-Document. Status should not be "RESOLVED FIXED"
Created attachment 173008 [details] buggy version 7.1.4
Created attachment 173009 [details] mostly fixed version 7.2.beta1
(In reply to Timur from comment #36) @Timur: You will find two videos showing the still existing problem in version 7.1.4. and the fixed version 7.2.beta1. However, the latter still does not correctly display the existing cell borders in the settings window.
*** Bug 143086 has been marked as a duplicate of this bug. ***
*** Bug 143083 has been marked as a duplicate of this bug. ***