Barbara Duprey [mailto:[email protected]] replied to my query:
> > If I'm reading this right, your table is insisting on > beginning at the start of a page. Have you > checked the table's Text Flow properties to make sure that > the Break-Page-Before options are not set? The box labelled "Break" is empty (intentionally, for exactly this reason - although that's the default setting anyway), so the four selectable options are grayed-out. HOWEVER, the "Page" and "Before" options (even though supposedly inactive) do have selection dots in them. It's not possible to empty the selection dots without filling the other two. Essentially, the designer of table behavior seems to be asserting "I will cause a break. You can select which break, but you can't select no break. I know what's good for you, better than you do." Leads me to assume the person is/was a Microsoft employee.... :-) [Little bit of frustrated editorializing there.] I have tried checking "Break" and then selecting "Page" "After" - no change. Well, the break does occur after the table, pushing the table footnote to the next page, but the change in properties has no effect on the _start_ of the table. I also tried "Column" "After", just to ensure that "Page" was not selected, and not for any desire to affect the column... again, no affect on page break before the table. If I then un-check the "Break" box, the options become gray, as-is... but later (after I close and re-open the document) they are back to the 'defaults' that they originally had. Anyway, that's part of what I meant when I said that I had played with Table properties, in addition to properties of the table elements. The height of the table heading row plus first content row is about 3.5 inches. The space under the text at the top of the preceding page is about 6.5 inches. The second content row, which is firmly stuck to the first content row, takes about 3 inches... considerably more than the body text on the preceding page, so it's absolutely dead-certain that there's no question of "fit" if the table flowed properly. "Properly" means, the way this OOo user wants it to. For another table, the situation is similar, though the heading row and first content row are alone on the page following body text. That's because the first content row and second content row together would be too big to reside on one page. Nevertheless, even though it breaks between the first content row and the second content row, that table still exerts "Break Before". I have even tried removing some useful text in the paragraphs before the table, to ensure that there were no lines of text at the top of the page preceding the table. If that page is TOTALLY empty, the table will slide into it. If a single paragraph marker is there, the table jumps, and leaves inches of air below the table break. I went so far as to shrink that table-preceding paragraph to smallest possible font size, with minimal height and para spacing. No go. The presence of a paragraph marker is a command to break before the table. Why? I'm probably overlooking something obvious. - kevinThe information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
