Suppose I select a couple of rows from a table, and on the Table menu, select "Heading rows repeat". Ok, so, now they repeat, but - what if only one of them is formatted as a header? And has the Table Heading style? How will I notice that the second line is also being repeated? Sure, I might be able to deduce this on inspection, but I would like for there to be some sort of indication, albeit subtle.
Some kind of a solution for this, albeit perhaps a bit _too_ subtle, would be an indication via the control available in the context menu for the row, see bug 156455.
The formatting of the paragraphs in the cells is not relevant for the "repeat rows" feature. How many rows are set to repeat is visible in the "Text flow" tab of the table properties and can be changed there. I do not understand your problem.
(In reply to Regina Henschel from comment #2) > The formatting of the paragraphs in the cells is not relevant for the > "repeat rows" feature. It's not formally relevant, but - it's relevant in terms of user experience and expectations. > How many rows are set to repeat is visible in the "Text flow" tab of the > table properties and can be changed there. I do not understand your problem. Oh, you're actually right! That did not even occur to me. So, let me rephrase the bug title. If the indication is hidden away somewhere that is not linked from where the repetition can be set, nor from some header-row-specific UI element, nor directly from the context menu for the header rows - then it is unlikely users will find it.
[Automated Action] NeedInfo-To-Unconfirmed
+0.5 to remove the (awkwardly labeled) command from the main menu -1 to add some indication or more interactions I don't buy the "users will not find" argument. If your table spawns over more than one page you start at least searching for a solution - and will find it easily. Large tables are nothing the average user will face in daily business and I disagree with the need to set header repetition in a over-convenient way.
(In reply to Heiko Tietze from comment #5) > +0.5 to remove the (awkwardly labeled) command from the main menu > -1 to add some indication or more interactions > > I don't buy the "users will not find" argument. If I haven't found it, few users will. > If your table spawns over > more than one page you start at least searching for a solution - and will > find it easily. Well, if the solution seems to be on the Table menu - you are unlikely to look elsewhere. If it is not there - if you know this feature exists, maybe you're more likely to find it; but if you don't - and many/most users don't - you are quite unlikely not to look for row properties in table properties (and in a vaguely-named tab to boot). > Large tables are nothing the average user will face in daily > business Heading rows repeat are just as important for smallish tables - since those often start near the bottom of the page, or end up starting there due to edits.
(In reply to Eyal Rozenberg from comment #0) > Sure, I might be able to deduce this on inspection. How? As a simple workaround, you can (enable,) disable and re-enable the repetition in the Table menu, and in the context menu (under Style) [and "in the 'Text flow' tab", from where I set the repeating rows ever]. I have not noticed the first two options until now.
We discussed the topic in the design meeting and agreed on having such an indicator together with a larger rework of the table management as suggested in bug 113603. We realized during the session that table styles always accept one rows as header, independently from the number of heading rows. Coming from Calc or Draw/Impress this makes sense but should reworked for Writer. If done it would provide a clear indication of header rows too. *** This bug has been marked as a duplicate of bug 113603 ***
(In reply to Heiko Tietze from comment #8) > We realized during the session that table styles always accept one rows as > header, independently from the number of heading rows. Coming from Calc or > Draw/Impress this makes sense but should reworked for Writer. If done it > would provide a clear indication of header rows too. ... and consequently, I've opened bug 157024 about this behavior of table "styles" (which are not styles).