Description: This is an ENHANCEMENT REQUEST to make the table attribute "merge adjacent line styles" merge borders between touching tables, as well as between rows within the table. Currently that option merges borders only between internal rows. This prevents double-width borders when adjacent rows (which have borders) appear together, but keeps the borders when a page break intervenes. However if two TABLES are adjacent (touching, no paragraph between), there is currently no way to prevent doubled borders and still have correct behavior at page breaks. If, for example, the top border of the tables is set to 'none' then doubling does not occur when the tables are adjacent, but when a page break intervenes then the first table on the next page appears with no border. USE CASE: Any table containing multiple sub-groups of data may want sub-groups to be kept together, but allow breaks between groups. The "obvious" solution is to put each group in a separate table with "allow table to be split" disabled. However then borders necessarily appear doubled between the sub-groups (i.e. where the separate tables touch), for the reason explained above. In my case I use a tool to generate "phone directory" type listings in an ODF document using a small table for each entry (https://metacpan.org/pod/ODF::MailMerge). There was an "ask Libre Office" thread about this which incorrectly advised users to delete top or bottom table borders to avoid doubled-up borders - see https://ask.libreoffice.org/t/writer-prevent-table-from-breaking-between-two-rows/45476 IMPLEMENTATION IDEAS: The existing "Merge adjacent line styles" appears to be implemented with the 'table:border-model' property, set to 'collapsing' (with Merge enabled) or 'separating'. Personally I think this existing feature could be silently extended so that 'collapsing' means also merge the outer borders of touching tables. There would be no effect on existing documents unless they contained tables with outer borders which were touching each other -- then the doubled borders would become single-width border (or the thickest one, using the "stronger attribute wins" rule). However if it is deemed necessary to introduce a new switch, then an LO extension would be needed. Could that just be a 3rd value for table:border-model (such as 'collapsing-enhanced')? I don't know anything about ODF extension protocol so can't say. Steps to Reproduce: n/a Actual Results: n/a Expected Results: n/a Reproducible: Always User Profile Reset: No Additional Info: n/a
Just to be clear, borders would still need to show on either side of a page break.
I'm not sure for 100% about your idea. So could you perhaps add a file that shows the problem a) between toiuching tables b) between rows within the table Thank you. => NEEDINFO
@Dieter Attached is a small demo .odt. The table borders are made extra thick so it is easy to see the doubling effect. --- While doing this I noticed what might be a bug in the existing implementation of "Merge Adjacent Line Styles". Instead of merging the lines when rendering, overlaped lines are completely deleted from the tree. In the 3rd table in the attachment, you can see that even though Adjacent Line merging is disabled, they appear to be merged anyway -- that is because the fo:border-top property is completely missing in all the rows except the first. As a result, when a page break intervenes, the top border is absent. More comments are in the demo file. Thanks.
Created attachment 189799 [details] TableBorderDemo.odt
Created attachment 189800 [details] screenshot.png
Created attachment 189801 [details] TableBorderDemo.odt (updated with non-Merging table split across pages)
https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1420300_253892949 The above link points to the ODF 1.3 spec for table:border-model. In brief, it says that when Merge is ON ("collapsing"), "each cell receives half the width of the border", and when Merge is OFF ("separating"), "borders appear within the cell that specifies the border". QUESTION: Does LO's implementation conform to this? I suspect not because: The 3rd (purple) table in the the attached (updated) demo has Merging NOT enabled (although it once did). Nevertheless, every row in that table uses the same cell style, with 'fo:border-bottom' => '4.5pt solid #5b277d' 'fo:border-top' => 'none', This explains why the top border is missing after a page break: There is no adjacent cell to cover the empty space. The ODF spec says that merging should occur only for *adjacent* cells, and cells are not adjacent when a page break intervenes. Doesn't this imply that table:border-model must be handled dynamically (i.e. during rendering) rather than statically deleting some borders? ------------ Also: If the user switches "Merge" on and off, it should not corrupt the border definitions set by the user. And: The current implementation might be shifting the content area incorrectly by half the border width. The ODF spec says 1/2 of the border should be in each cell, and so the content area (the part inside the borders) should be centered; doesn't setting one border to "none" shift the content area to be off-center? ------------- (To be clear I am not an ODF expert; I'm just trying to shed light on the problem.)
Created attachment 189803 [details] TableBorderDemo.odt (try #3; I think it is like I described now)
[Automated Action] NeedInfo-To-Unconfirmed
Regina and Miklos, I'm CCing you in case you want to chime in regarding ODF specs and table behaviour across pages respectively. Jim, please share here what version of LO you used for your tests. Thank you!
I see no need for a change in file format. Each of the four cell borders can be styled individually. So the user can style the bottom edge of the bottom cells of the first table and the top edge of the top cells of the second table to get the desired appearance. These settings can be stored in file format. We might extend the user interface to make it easier for the user to perform such settings. We might reconsider the decision to set a border initially to empty, if the table is set to "collapse border" and the border of this cell would be hidden. But both affects only how LibreOffice works with tables and does not affect the file format.
> Each of the four cell borders can be styled individually. So the user can style the bottom edge of the bottom cells of the first table and the top edge of the top cells of the second table to get the desired appearance Hi Regina, How can the user avoid the doubling problem? That is, avoid doubling when tables are touching yet still show all borders when a page-break intervenes? For example, if the top border is set to none then there is no doubling when the tables touch, but if there is a page-break then the table at the top of the new page is missing a top border.
@Stéphane Guillou -- I've been using both 7.5.6.2 and master builds (24.2alpha)
(In reply to Jim Avera from comment #12) > Hi Regina, > > How can the user avoid the doubling problem? That is, avoid doubling when > tables are touching yet still show all borders when a page-break intervenes? The user sets the border to half thickness when the tables are on same page and on full thickness when tables on different pages. I do not like to introduce a special border handling for a case, in which it would be one table in content and you only split this table to solve a "keep together" problem. Instead a solution for the "keep together a group of rows" is needed.
(In reply to Regina Henschel from comment #15) > Instead a solution for the "keep together a group of > rows" is needed. The enhancement requests in bug 148975 and bug 125972 could help.
> The user sets the border to half thickness when the tables are on same page and > on full thickness when tables on different pages. Ok, I think this is the point of misunderstanding. The user can not do that because the user can not know where page breaks will occur. The height of each table is unpredictable because it is data-dependent (e.g. sometimes line wraps occur, making rows higher etc.) and thererfore a long list of touching tables will be split across pages unpredictably. It is not subject to human formatting of individual tables because the data is generated and inserted with software (you can imagine LibreOffice macros doing it, although in my application the technology is different).