Created attachment 199230 [details] file with a table exhibiting vertical padding problem Documentation states: "Padding specifies how much space to leave between the border and the cell contents. Spacing can be specified individually for the left, right, top, and bottom borders. Choose Synchronize to have the same spacing on all four sides." Use the attached document. Click within the text of "NAME FIELD" in Row 4. Table-->Select-->Cell Table-->Properties (Borders tab) Observe that Padding.Synchronize is off and Padding.Bottom is 0.00. Dismiss Properties dialog. Actual behavior: there is some bottom padding visibly applied to text in this cell (compare to row 1) even when the Properties dialog has it set to 0.00. Expected behavior:the text "NAME FIELD" should have no bottom padding and be aligned with the bottom of the cell. Continue: Click within the text of "123.45" in Row 4. Table-->Select-->Cell Table-->Properties Observe that Padding.Bottom is 0.06. Actual behavior: there is some bottom padding visibly applied to text in this cell [correct], but also aaplied to the cell in Col. 4, even though column 4's cell Properties dialog has it set to 0.00 [not correct]. Now change Padding.Bottom from 0.06 to 0.00 and press OK (or: tab to OK and press Enter). Actual behavior: both the text "NAME FIELD" and "123.45" cells are set to 0.00 bottom padding. Expected behavior: the text "NAME FIELD" should not be affected by a bottom padding change in "123.45" cell. Changes to top and bottom padding should be applied only to the selected cell(s), not the entire row, just like changes to left padding correctly do. Also expected behavior: For all 4 Padding settings: the padding of text in any selected selected cell(s) should match that cell's settings at all times, and changing a setting for one cell should not change it in any other cell. Comment: changes to Padding.Left in one cell do not affect other cells [correct behavior]. Problem seems limited to Padding.Bottom and Padding.Top (visible when text is formatted vertical alignment Bottom and alignment Top, respectively). Horizontal padding behaves correctly and vertical does not (copy/paste error in code?).
Reproducible with: Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: ee3885777aa7032db5a9b65deec9457448a91162 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: es-MX (es_ES); UI: en-US Calc: CL threaded But problem is solved if you unmark "[ ] Merge adjacent line styles" (in Borders tab). So, maybe Not a but.
(In reply to LeroyG from comment #1) > But problem is solved if you unmark "[ ] Merge adjacent line styles" (in > Borders tab). > > So, maybe Not a [bug]. Yes, I observe that too. However, that doesn't explain why the horizontal and vertical padding are treated differently. It is my opinion that horizontal padding is treated correctly (padding as a cell attribute). "Merge adjacent line styles" appears to be a global setting on the entire table, not a cell specific attribute. Changing it in the attached file also completely changes how it appears (grid disappears, very obvious in Dark Mode) although I'm not sure exactly why since I have the borders removed and the Tools.Options color for Table Boundaries set to Light Yellow 4 in Application colors. I digress. "Merge adjacent line styles" is defined in the manual as: "If Merge adjacent line styles (under Properties) is checked, two cells sharing a common border will have their borders merged, rather than being side by side or above/below each other." It doesn't describe if it applies to the whole table, so I'm not quite clear on that setting, but it does not seem to be applied to the selection whereas, like Text Alignment, Padding (at least Left and Right) does -- which makes sense to me. Furthermore, Padding is not a line style and neither a border nor part of the border (rather, padding is part of the cell content) so it shouldn't be merged to adjacent cells that share a border unless of course multiple cells are selected when changing padding. And certainly, Left padding should not act differently from Bottom padding in that regard. That would be inconsistent. As an aside, if the Merge property *is* a Table attribute, perhaps the text in the Borders tab ("Properties Merge adjacent line styles") should add "across entire table" and/or clarified in the manual.
(In reply to Barry L. Kramer from comment #2) > "Merge adjacent line styles" appears to be a global setting on the entire > table, not a cell specific attribute. After a few test I can confirm that it is a table attribute.
(In reply to Barry L. Kramer from comment #0) > Observe that Padding.Synchronize is off... It's on for me. > Actual behavior: there is some bottom padding visibly... > Expected behavior:the text "NAME FIELD" should have no bottom padding... Well, observe is not apply. If you change the value to 0.1, apply per okay, and change it back to zero it works as expected. Now the question is how you got there - a padding when values are zero. Unclear to me, and I cannot replicate with a simple table. > Observe that Padding.Bottom is 0.06. It's zero. And looks like the same issue as above. In a nutshell: border padding on the table properties is applied to all cells, and "[ ] Synchronize" does not change the attributes (as we don't know which of the four should be taken into the other fields). I don't see much room for enhancement, or does ODF allow cell level properties in Writer? As an alternative workflow you might consider to use paragraph properties. Each cell has its own paragraph with indentation and spacing.
(In reply to Heiko Tietze from comment #4) > Now the question is how you got there... > I cannot replicate with a simple table. => NEEDINFO
Please let me clarify what I was originally reporting here, as the title of this issue doesn't really reflect the issue that concerned me. The problem I was describing is that there is something wrong with top and bottom padding of a table cell, whereas the left and right padding of a table cell work correctly (and can be adjusted per cell). I will attach another file which is just a new file with a simple 4x4 table inserted. These simplified instructions show my concern. To set this up: open the bug 165275test1.odt file click in any table cell table select table table properties borders(tab) leave [x] synchronize enabled, and set left (therefore all) to 0.4 in; OK --> observe that (correctly) all cells have visible top, bottom, left, and right padding. To see the issue: Click in any cell such as B2 table select cell table properties uncheck [ ] synchronize in Padding, change Left to 0, OK. --> observe there’s (correctly) no left padding. table select cell table properties uncheck [ ] synchronize (if checked) in Padding, change Bottom to 0, OK. --> observe that (incorrectly) it didn’t do anything. Bottom padding is still 0.4 in. Expected behavior is the text "B2" should be against the bottom cell border with no bottom padding. If padding (left, right, top, bottom) can be specified for individual cells (which it should be), then all four should be able to be set individually and independent of other cells that are not selected when it is set by the user. I reiterate this point from my original report: Padding is not a line style and is neither a border nor part of the border. Rather, padding is part of the cell content (an attribute of it), so it shouldn't be merged to adjacent cells that share a border unless of course multiple cells are selected when changing padding. And certainly, Left/right padding should not act differently from Bottom/top padding. That is inconsistent. Version: 25.2.7.2 (X86_64) / LibreOffice Community Build ID: 5cbfd1ab6520636bb5f7b99185aa69bd7456825d CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 205016 [details] a simple test file for this issue
It seems that the first column defines the top and bottom padding for all the row.
I think, it is not a problem of documentation of the "Merge adjacent line styles" feature. But the implementation is wrong, not only in regard of the bottom border. LibreOffice calculates the content area wrongly. The corresponding ODF 1.4 attribute is 20.415 table:border-model It has the text, "collapsing: when two adjacent cells have different borders, the wider border appears as the border between the cells. Each cell receives half of the width of the border." You can see the problems better, if you increase the border width and set a fixed height for the table cells. When testing the position of the text, it is helpful to apply a background color to the paragraph. And it is needed to check the vertical alignment of the text in the content area in Format > Align Text.
(In reply to LeroyG from comment #8) > It seems that the first column defines the top and bottom padding for all > the row. I don't quite see that behavior. What I observe is that an *increase* in the bottom padding of any selected cell will increase the bottom padding for all the cells in a row (and naturally increasing the row height to accommodate the increase). However, a *decrease* in the bottom padding doesn't seem to do anything at all, even if the whole row is selected. Decreases to bottom padding do work but only if the whole table is selected. In contrast, changes to left padding work properly when any cell, row, or column is selected, and the left padding setting is stored on a per-cell basis. What I would expect with an increase in bottom padding of any one selected cell is that the row height is increased as needed (like it works now) but that the bottom padding of that cell becomes the new value for only that cell, and not for the other cells in the row (which should be left alone). Currently it does affect all the cells in the row and I think that's wrong. It seems the top/bottom padding values aren't stored per cell so changing the values have side effects and prevents the user from decreasing the bottom padding once it is nonzero.
Not sure if this is helpful but I looked up ODF 1.4 and it appears that left, right, top, and bottom padding are supported as table cell attributes. This was also found in the ODF 1.2 spec from 2011. From ODF 1.4: 17.18 <style:table-cell-properties> The <style:table-cell-properties> element specifies formatting properties for cells. The <style:table-cell-properties> element has the following attributes: fo:background-color 20.182, fo:border 20.183.2, fo:border-bottom 20.183.3, fo:border-left 20.183.4, fo:border-right 20.183.5, fo:border-top 20.183.6, fo:padding 20.217, fo:padding-bottom 20.218, fo:padding-left 20.219, fo:padding-right 20.220, fo:padding-top 20.221, ... Finally, I wanted to reiterate that the issue I'm writing about here is about table cell vertical padding, not anything to do with borders. Hopefully my explanations are clear; if not, I can take some screenshots.
(In reply to Barry L. Kramer from comment #11) > Finally, I wanted to reiterate that the issue I'm writing about here is > about table cell vertical padding, not anything to do with borders. > Hopefully my explanations are clear; if not, I can take some screenshots. The error happens, when collapsing borders is enabled. Then the content area is wrongly calculated.
Don't really follow the collapsing border argument. The zero padding works if applied to the whole row. But obviously not to a single cell neither it persists when the surrounding cells have some padding. In any case, it's an ordinary bug and not a question to UX. Removing the keyword.
(In reply to Heiko Tietze from comment #13) > In any case, it's an ordinary bug and not a question to UX. Removing the > keyword. Perhaps the entire title of this incident should be changed back to my original one when I first reported it? "Top+Bottom padding not correctly applied to selected cell(s) in table row" This was changed on Oct. 28, 2025.
(In reply to Regina Henschel from comment #12) > The error happens, when collapsing borders is enabled. Then the content area > is wrongly calculated. Is "collapsing borders" enabled mean "Merge adjacent line styles"? I don't observe that "Merge adjacent line styles" affects my ability to set the bottom padding of a cell. If I set that to disabled, I still have the same problem: setting the bottom padding to a smaller value doesn't do anything if another cell in the same row has a larger bottom padding. However, it does seem that the top, left, and right padding can be set both higher and lower. Maybe there is just a typo in the code dealing with the bottom. Are you describing a different problem? I don't understand what you mean by the content area. Could you upload the file you're using?
Created attachment 205046 [details] Example with deselect merge > Is "collapsing borders" enabled mean "Merge adjacent line styles"? Yes, "collapsing" is the value of the table:border-model in file markup, when the option "Merge adjacent line styles" is _not_ checked. > I don't understand what you mean by the content area. "content area" is the actual area in which text can appear. You have for each cell horizontally left border | left padding | content area | right padding | right border and vertically top border | top padding | content area | bottom padding | bottom border. If "Merge adjacent line styles" is enabled, then the thicker of the adjacent borders should be rendered and each affected cell receives halve of this border width. (see cited specification) I have attached a file with merging disabled. The yellow border has width 4pt, the green border has width 7pt and the blue border has width 9pt. Open the file, mark the entire table and enable merging. I see these errors: (a) Top padding uses the maximum of the cells in the row instead of the individual values of the cells. (b) Bottom padding uses the maximum of the cells in the row instead of the individual values of the cells. (c) Left padding is measured from the middle of the border instead of the edge of the border. Thus text is behind the border. (d) Not in all cases the wider of two adjacent borders is rendered.