<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Entering a table with too many columns causing Writer to lock up" href="https://bugs.documentfoundation.org/show_bug.cgi?id=134779#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Entering a table with too many columns causing Writer to lock up" href="https://bugs.documentfoundation.org/show_bug.cgi?id=134779">bug 134779</a> from <a class="email" href="mailto:abdekker.online@gmail.com" title="abdekker <abdekker.online@gmail.com>"> abdekker</a> <pre>(In reply to Heiko Tietze from <a href="show_bug.cgi?id=134779#c4">comment #4</a>) > We discussed the topic in the design meeting: > + WPS limits to 63 (Patrick) > + it's still possible to add rows/columns before/after (Heiko) > + just a performance issue, limitations are bad (Csongor) > + show a warning per coloring the spin edit or per confirmation box > => go with the colored warning > > Taking Justin's comment into account we should warn starting with 64 columns > (and perhaps 255 rows?) with "Large tables might adverse performance and > compatibility". > > Some code pointer: > > sw/source/ui/table/instable.cxx > m_xColNF->set_message_type(weld::EntryMessageType::Error/Normal) Cool, you guys decide what to do, but I do have one comment. Csongor's implication that "limits are bad" is not justified. Of course, you might argue where that limit might be (say 99 or 200 or 1000 or 100 billion), but everything has a limit. I doubt there is any realistic use case where a user will want more than a few hundred columns in LibreOffice Writer. If they *really* wanted to load a super-large spreadsheet, they'd use Calc not Writer. In Writer, tables are totally unreadable after a few hundred columns. You'd need truely gargantuan resolution to read a single character with just a few hundred. Make a stand! Maybe set the limit higher (255 or 1000 or whatever), but if anyone complains, "I have a use case where I need twice as many columns" or no-one complains, you've learnt something. Setting no effective limit under the premise "limits are bad" and assuming someone, somewhere uses thousands of columns is "shotting in the dark"! :o) Warnings are good, but why mask with a warning a feature that will have negative consequences ranging from minor (unreadable table) to serious (application crashes, potentially loses all unsaved work)? Whatever you decide to do, good luck and thanks! Alain</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>