https://bugs.documentfoundation.org/show_bug.cgi?id=162523
--- Comment #4 from ajlittoz <[email protected]> --- I looked at the attachment. It is configured for Web View, probably to circumvent performance issues. When I try to restore Normal View, Writer no longer responds and I kill it after some "reasonable" delay. As a consequence I could not determine how many rows of the table span several pages. A similar case was mentioned on AskLO where a table row spanned tens of pages. I concluded that a cell is considered as an independent sub-document and Writer loads the whole cell contents in memory before computing page breaks. And this is aggravated by the number of columns in the row, putting considerable stress on system memory management. The document has two tables, but they extend over a considerable number of pages. This could be a contributing factor. I met a similar issue with a user question on AskLO. Once the "monster rows" were split to single paragraph contents, the problem was partially solved. Splitting the table in smaller ones and eliminating omni-present direct formatting did the rest. So, author should check if (s)he abuses the table feature. Writer tables are intended to host short TABULAR text, not full text flow. What is the pupose of the 4-column table? Simultaneous translation in foreign languages? In this case a table is the unavoidable solution but care should be taken to limit the amount of data and avoid as much as possible rows spanning several pages. -- You are receiving this mail because: You are the assignee for the bug.
