Please share a sample file. Thank you.
Additionally tell LO version and OS.
2 Likes
I assume you created the caption with Insert>Caption which has the side effect of enclosing the table and the caption inside a frame. A frame is an “atomic” object. If combined size of table and caption is such that it does not fit in the remaining page space, it is flushed to next page. And a frame can’t straddle page boundaries (it is limited to a single page). Then a huge table will be clipped to the size of the frame.
The solution is to create your table “as usual”, allowing it to be split across pages and to add manually the caption. A caption has nothing special or “sacred”. It is a standard paragraph with a dedicated paragraph style. What turns it into a “caption” is the presence of a number range field. Insert manually this field and add the other elements of an automatic caption. Writer will not make any difference with other “captions”. You simply avoid the surrounding frame which is causing the problem.
See OP.
A request for information which is provided in OP gets a like yet it does it twice?
Thanks for information. Subsequently to creating this question I did further work on the document in focus here. However, that work addressed other aspects (adding content to table as well as to paragraphs outside table) - not the problem targeted here, as I didn’t know how to approach it.
Few minutes ago back to working on this document and what I encounter is splitting of table mentioned to two subsequent pages. I have no idea how it happened.
Q.1 If a table is put to frame and it happened by attaching a caption to table, will it be possible to see the frame in navigator?
Q.2 Will it be possible to move the table from frame to text area outside frame?
I have checked Writer Guide, and Writer Help for presence of relevant warnings. None was found in Writer Guide. One found in Writer Help, however not unambiguous enough one. That one in Help - its position in Help text is: Special Text Documents > Using Captions > green pinned field on the top of this help section. It is ambiguous because field addresses not only tables, it addresses also objects, it is unclear if table is an object. Please take also a short look at blue field at bottom of the same Help section, table is differentiated from object - based on this statement I make the conclusion table to be no object.
The like may also be for the suggestion to upload a sample problematic file.
It is often difficult to diagnose a problem from a description.
Usually the table’s caption is not put into a frame. Maybe @ajlittoz could explain that this is a regular procedure…
Good question. You have to copy the table, then delete it in the frame, IMHO
LOL - what about the sample file?
I answered too quickly. Insert>Caption creates a frame, except for tables. Consequently, I can’t suggest anything without a sample file.
1 Like
@ajlittoz’s mind is attaching a caption to a table is placing the caption and table in a frame. My objective at this point is the placement of table on pages, not the mere caption. I also have in my mind that if document autor finds in Writer GUI the functionality “insert a caption”, or she/he does it in Writer documentation, the user will on the natural and instinctive way follow this proposal instead of to start searching for alternatives.
The highly annoying property of Writer is that a huge number of features exist and Writer documentation seeks to “sell” all those to user but as soon as one tries to follow the “offering” the recommendations is frequently encountered read “do not use it”.
Unfortunately, it is not always easy to follow these kind request, because in this particular case I am not the only owner of contents in document, there are other persons who decide when, in which parts, yet on which ways the document goes to public.
I asked Q.1 and Q.2 for use in future, to gain general understanding - these are not specific for the current problem. I agree both got answered in @ajlittoz’s latest reply Giant part of page unintentionally blank because of table - #7 by Grantler
Which are the candidate formatting settings by which problem described in OP may arise? Is the set of such settings huge?
The point is perhaps that it is not a “predefined set” of single settings, but also various combinations of (possibly unexpected) settings. Making a list of possible settings and combinations of settings is a challenge.
Rather than expecting us to make a list (which will most likely be incomplete), consider making a sample document. Create a copy of your file, and replace every letter with “X”, and remove user info from document properties (the File menu). That should remove all that forbids publishing.
Pretty smart argument. I suppose you even couldn’t anonymize the file because of your in-built decision makers. 
I see, Thanks.
Writer initially provides “basic bricks” to build a document. Unfortunately too many users don’t take the time to learn what these basic bricks are, not reading the existing documentation (which unfortunately is not oriented towards this goal). Combining these bricks is quite boring because many steps are necessary. This can be alleviated by creating AutoText entries, but, just like templates, this is seldom done by beginners and even regular users. Too many people dive in a hurry into document creation without taking the time to think about document structure and abstracting it.
As a consequence, this results in numerous feature requests to add procedural shortcuts, like Insert>Caption. Since this is a procedure, implementors choose on their own what they think would satisfy the majority of users. This compromise may conflict with author’s preferences.
But you still have the option not to use these procedural shortcuts and generate yourself manually what is needed to be conformant with your formatting/layout guidelines.
Once again, I can’t suggest anything without seeing what you’ve done. Either you attach an anonymised version of your document or you create a representative sample file. Failing that, stop writing your document and learn how to use Writer. Every tool needs a change of procedure. Do you use a screwdriver as a hammer to crush nails? Or a hammer to drive screws?
As @ajlittoz mentioned above, their seems to be no frame around a table.
AFAIK, has LO-Writer many shortcomings since ever in tables.
If I understand the releasenotes of LO 24.2. right, there are some improvements of Miklos Vajna in respect of Multi-page floating tables. This seems to me related to this topic.
Could it be helpful, to give the improvements in LO 24.2 a try?
For informations see :Release Notes LO 24.2
It seems to be an ongoing work…
Had always really adequate and acceptable efforts to learn hammer and screwdriver proper usage then no probs on following it consequently yet in sustainable way. In case of Word 97 it was possible to learn and master style-based writing in acceptable time (had no occasion to do it with later Word versions as far it concerns this sort of writing).
It is hard to learn with sustainable effects without hands-on sessions.
One can believe or not, I try to use documentation. The problems are:
- it frequently does not address the numerous exceptions yet the recommendations received on ask.libreoffice; it happens to be ambiguous
- it is not abnormal to expect software app to be intuitive in usage
I decided to proceed in a fashion with tool-support (I consider style-based writing to be such) to increase the chance for my productivity. Based on general experience I don’t consider manual work to be enabling satisfying productivity.
Thanks for your proposal.
24.x is closer to bleeding edge than 7.6 - I see higher risks of troubles, hence rather not to accept in this case.
Duration of this particular writing is a number of weeks in scope of which a series of troubles get encountered and lot of Writer features get used. It is not reasonable to orientate just on the tables-related point when making my decisions.
I can recreate following your steps using LibreOffice 7.3.5.2 and I suppose it exists in 24.1 which I cannot test at the moment. If the table exceeds one page in size then it flows correctly but if the table is larger than the space in the page it is inserted then it gets pushed to the next page.
BigTableAfterText.odt (14.6 KB)
You could report a bug, How to Report Bugs in LibreOffice - The Document Foundation Wiki
1 Like
@EarnestAl Thanks for the effort you undertook. I am not ready to conduct the switch to 24 as I consider it to be closer to bleeding edge than its predecessors which is not good for my current writing.
I didn’t got how the both cases differentiate; on another side my latest observation reads: certain number of cells is multi-line (multi-paragraph)* yet depending on the overall sum of lines in all table rows the problematic behavior occurs or does not. This explains previous my observation reported in Giant part of page unintentionally blank because of table - #5 by eighty2
*) Sorry for hadn’t mention it previously
Seems to be a point of “Keep with next paragraph” (table properties, Text Flow). If I deselect this option the table behaves regularly. I agree that this could be a bug.