Description: In Writer, repeat the first column (not line) on the next page(s). In my case, start and end times are in the first column, but the table is too 'wide' for one page. Therefore, the times should be repeated on the following pages as a repeated first column and be the same everywhere after changes. This is possible with Calc, at least for printing: [Print row or column on each page](https://help.libreoffice.org/7.5/de/text/scalc/guide/print_title_row.html) Steps to Reproduce: (Does not exist yet, confirmed on the German Ask LibreOffice: https://ask.libreoffice.org/t/writer-erste-spalte-einer-tabelle-auf-folgeseiten-wiederholen/95946) Actual Results: Separate tables with first columns requiring manual synchronization on each page. Expected Results: Same content of the first column, edited once, is shown on every page's first column. Tables don't have to be split for each page. Reproducible: Always User Profile Reset: No Additional Info: Keeping the information in the first column synchronized is tedious and error prone. Additionally, the table has to be split to provide this feature, which is adding to the complexity.
Thanks for the suggestion ssantos. It has been asked about on English-language Ask.LO as well: https://ask.libreoffice.org/t/how-to-repeat-the-contents-of-a-column-across-pages/8136 I understand such a feature would depend on the ability of a table splitting columns across pages as opposed to splitting rows, and I can hardly imagine this happening as content flows top-to-bottom into the next page, and table widths are limited to between the side margins of a page... So "won't fix"? Or maybe I'm missing something relating to orientation and Complex Text Layout? -> needsUXEval and needsDevAdvice.
From the ODF spec 8.2.2 Header Columns If a table does not fit on a single page, a set of adjacent table columns can be automatically repeated on every page... So it should be possible. Right, Regina?
(In reply to Stéphane Guillou (stragu) from comment #1) > I understand such a feature would depend on the ability of a table splitting > columns across pages as opposed to splitting rows Well, not necessarily. One could image a user doing the column-splitting themselves, apriori, but wanting the first column repeated. Example: A daily itinerary table, with different days on different pages. First column(s) should an hour range. Also, if this is implemented, remember the directions: * Of the table * Of the page * Of the paragraph and decide which of these should affect which column gets repeated. Probably the table direction. Also remember that, currently, the direction property of the table is labeled "Text direction" - even though it's not just the text direction (bug 157819).
Sorry, I was being nonsensical in my last comment, please ignore it.
Hi Santos, (In reply to ssantos@web.de from comment #0) > In my case, start and end times are in the first column, but the table is > too 'wide' for one page.... I think the problem already starts with the fact that tables that are too wide, do not wrap ... You have to split it yourself??
Hi Santos, What about using Calc? Define a print range, and there you define rows to be repeated.. And use page styles for more beauty. greetings, Cor
We discussed the topic in the design meeting. As Cor mentioned in comment 6, Calc provides means to repeat row(s) and column(s) for a print range. Tables with overflowing columns is unusual in Writer (could be done for the pivoted table with rotated text). Resolving the ticket as WF, feel free to reopen with arguments why Writer needs this feature.
The reason why I would not do it in Calc is that I have a timetable on a multipage text document too wide to fit onto a page, Calc lacks word processor capabilities for the rest of the content, and I am not calculating anything. The problem when splitting it is to change the timing in synch over page borders. Imagine the quality problem and confusion if it had not been found last minute, and the trigger for this enhancement report.
(In reply to ssantos@web.de from comment #8) > The reason why I would not do it in Calc is that I have a timetable on a > multipage text document too wide to fit onto a page,... You add the table to each page, I think?
Yes, I have to add a separate table on each new page, but the first column has to be the same on all of them. So, when the time in that column is changed, it has to be done in parallel of all the other pages, or else you complete the changes on one page and then have to manually replicate them by scrolling back and forth with the risk of mistakes. I tried both, none of these options are satisfactory.
(In reply to ssantos@web.de from comment #10) > I tried both, none of these options are satisfactory. Why don't you use Calc?
Hi SSantos, (In reply to ssantos@web.de from comment #10) > Yes, I have to add a separate table on each new page, but the first column > has to be the same on all of them. So, when the time in that column is > changed, it has to be done in parallel of all the other pages, or else you I understand that. > complete the changes on one page and then have to manually replicate them by > scrolling back and forth with the risk of mistakes. I tried both, none of > these options are satisfactory. To make your life here easier, you can * select A1:An in the first table * copy * put the cursor in A1 on the next table * paste * etc. Still some work, but assuming you do not change the first column every day.. Alternatively ... you can copy the text content of a cell, and paste special as DDE-link to the same cell in the other tables. And when content changed, update with Edit > External Links. That however easily breaks with changing the content of the cells. I didn't look into options with (linked) sections. Anyhow, since there is/are reasonable alternative(s) to get this done, and since implementing your idea (as such not bad) is far from trivial, I hope you can live with a 'works for me'..? greetings - Cor
For reporter: please do not change status, if it was triaged by a member of TDF. You are still welcome to add comments and object a resolutions. For Cor: WFM is wrong here, akthough it wounds good, it is not so. WFM is when there was a bug that is fixed with unknown commit, indicating possible reverse bibisect. Should be clear from https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status I revert to Heiko's previous WontFix. Although let us call it soft, it there is a dev willing to fo this, it would be welcome. But keeping it open would give some legitimacy to expecting it, which is far fetched.