Description: Hi,time ago I filed the bug 151362 which pointed out a bad behavior of LO with large files and tables. Since this keeps happening not only with big files, but also with very small ones, I decided to file this new bug. We use two- or three-columns documents for translations and then copy paste the part to be revised in a A5 template (to read it in pdf on a Remarkable for ex.). Then we create a pdf. But this bug is hampering our work. The bug seems to happen even with very small texts when footnotes are added in a text within a table (we use 2 cells, but it may happen with only one). The adding of such footnotes (to both columns) results in 1. Table split in very inconvenient way for revision (I sometimes had a 2 page document split into 6 or 7) 2. Text of part of cell disappears below visible portion of screen 3. The adding of footnotes eventually results in the crashing of LO Attached you'll have file called "without footnotes" to do follow all the steps described below. The one called "with footnotes" shows the actual result (1 and 2 above) if you keep adding long footnotes LO will block. Steps to Reproduce: 1.Open a five A4 long text (or use the attachment "Without footnotes" provided and jump to point 4) 2. Convert text into Table 3. Add a new column, select text in column1 and paste it in column2 (we do so for translations, but the attached file is in one language) 4. Copy half of the first paragraph. 5. Insert 2 footnotes per cell both on the left and on the right column pasting the text you copied (I paste it as only text, but any paste will do) Actual Results: 1. Table split in very inconvenient way for revision (I sometimes had a 2 page document split into 6 or 7) 2. Text of part of cell disappears below visible portion of screen 3. The adding of footnotes eventually results in the crashing of LO I created 3 bookmarks: Bookmark 1 Column split, Bookmark 2 Column disappears, Bookmark 2 Column split but I noticed that upon reopening now Cells are not badly split corresponding to Bookmark 1 Column split, while the other two still exist. Refer to pdf to see what I saw the first time. Expected Results: 1. Table should not be split before the end of available space on an A4 or A5 (see attached pdfs created for both texts with footnotes and without) 2. Text of part of cell should not disappear below visible portion of screen 3. The adding of footnotes eventually results in the crashing of LO Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en.UTF-8); UI: en-US Calc: threaded
Created attachment 195669 [details] Test file odt with footnotes
Created attachment 195670 [details] Test file odt with footnotes pdf
Created attachment 195671 [details] Test file odt without footnotes
Created attachment 195672 [details] Test file odt without footnotes pdf
(In reply to Daniele from comment #0) I've tested with Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded and attachment 195671 [details]. First I've deleted all bookmarks and comments to make sure, that the bug is not related to that. I'v added 16 footnotes but there was no crash > 1. Table split in very inconvenient way for revision (I sometimes had a 2 > page document split into 6 or 7) i confirm this, but I think this has already been reported for example in bug 129747 > 2. Text of part of cell disappears below visible portion of screen This is more or less your bug 151360 > 3. The adding of footnotes eventually results in the crashing of LO I can't confrim this (pershaps bacause I use Windows) It's always difficult to mix differnt issues in one report, so I suggest to focus on the crash.
Hi Dieter, thanks! I concentrated on the crash as you suggested and could not reproduce the crash with my own file. I do not know why. So I think that this, as far as the crash goes can be closed.