When a table is inserted in Writer, the checkbox 'Allow row to break across pages and columns' is checked by default. When a row contains a page break, part of the row will be on the first page, and the rest will be on the next page. This is confusing for blind users with a screen reader, because the row will be presented as two separate rows. When creating accessible documents, this checkbox needs to be unchecked for every single table, which is a lot of work when you need to make other people's documents accessible. Steps to reproduce the issue: 1. In a Writer document, go to Table -> Insert Table, and insert a table. 2. With the cursor still inside the table, go to Table -> Table properties -> Text Flow tab; the checkbox 'Allow row to break across pages and columns' is checked, so uncheck it. There is no workaround for this issue. I think the vast majority of tables don't need this option anyway (because they are relatively small and simple), so unchecking it creates no negative side effects for the majority of authors.
Hi :) Again i think this is an Accessibility issue. Christophe Strobe's bug reports are often likely to be about Accessibility issues so although there is not an official tag it might help to search using his name as a parameter. Regards from Tom :)
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Version info was previously unspecified. I confirm that this 'bug' still applies to LibreOffice 3.5.0 RC1: the checkbox 'Allow row to break across pages and columns' is checked by default (= on newly created tables). Changing the status from NEEDINFO to NEW.
reproduced in LibO 3.6.0 master on Fedora 64 bit I agree that it is important
Hello, I know it's an old bug, but I need also to have tis option uncheck. Can you tell me where (in the code) I can do this? Thank you very much.
On pc Debian x86-64 with master sources updated yesterday, I could still reproduce this. A code pointer to start: http://opengrok.libreoffice.org/xref/core/sw/source/ui/table/tabledlg.cxx#1475
https://gerrit.libreoffice.org/#/c/12371/ Waiting for feedback from devs because it may have some impacts on different locations.
Niklas/ux team: I submitted a patch for review but thought meanwhile you might be interested in this one. I'd just like to know if this tracker is ok for you or if you thought about wrong side effect.
I'd say that the main side effect will be for people (ab)using tables for layout. If you have a cell that contains lets say 10 lines and the whole cell suddenly gets moved to the next page, this will likely make quite a few persons frustrated, wondering what happened. Before changing this I would strongly suggest that we add the option to the dialog that is shown when pressing Ctrl + F12. When testing this issue I noticed that the split button was changed into a drop down button which hides these options even more. On the other hand I'm not to found of split buttons so ... Btw. have a look at Tools -> Options -> LibreOffice Writer -> Table. It would be great to have the default setting set-able there. Wishful thinking from my side, possibly horrifying for some of the UX-people. ;) I will however add that this is a setting that I pretty much always change, along with ticking in that the first row should be considered a heading row that should be repeated if broken across a page break. This is not only for accessibility reasons but because I want the data in the cells to be kept together. Summary: I'd be careful changing this behavior, at least until we have a check box in the options dialog and the insert table dialog.
Thank you Niklas for your feedback. Badfully, I never changed a dialog after ui conversion and don't know anything about Glade. So if this change is required, I couldn't help here :-( Samuel: put you on cc because you might too be interested in this one and I don't think you're on ux team (perhaps I'm wrong).
Unassign myself since I won't be able to do the job here. I abandonned the patch which was in gerrit review (see comment7).
Migrating Whiteboard tags to Keywords:(needDevEval -> needsDevEval) (Harmonize spelling of term)
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
The "Don't split table over pages" option was added to the table creation dialog. So this ticket is resolved. Cannot say when it was done so I set WFM. Version: 5.2.0.3 Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; Locale: de-DE (en_US.UTF-8)
This issue is not resolved. I assume that its status was set to "Resolved" due to a misunderstanding of what this is about. It is explicitly about the option "Allow ROW to break across pages and columns" and not about the related option (also on the Text Flow tab of the Table Properties dialog) "Allow TABLE to split across pages and columns". When a page break occurs within a table row, a screen reader will treat it as two separate rows, i.e. one on the first page and one on the following page. This can completely mess up the meaning of the table and render it near-incomprehensible to a screen-reader user. To check whether the issue is still present, I have reset my LibreOffice profile (as explained at https://wiki.documentfoundation.org/Faq/General/110#Resolving_corruption ) in LibreOffice 7.1.4.2 on Windows 10, created a table and checked the table properties. The setting "Allow ROW to break across pages and columns" was enabled by default. (I actually teach colleagues and other people how to create accessible documents and need to point out each time that this setting needs to be disabled for accessibility reasons.) For this reason, I'm setting this issue but to "NEW" again.
(In reply to Niklas Johansson from comment #9) > If you have a cell that contains lets say 10 lines and the whole > cell suddenly gets moved to the next page, this will likely make quite a few > persons frustrated, wondering what happened. Sounds like a minor inconvenience compared to the a11y issue. So I'd do it. But implementation is a bit tricky since the option is part of table styles (TS) where we don't have easy access (bug 49437). And it depends on whether a table is created from the toolbar widget or via Insert Table what TS is being used.