sticky keeps problem

[ptc-2916524]

Hello good folks,



I have two sections, A and B, which consume two pages, 1 and 2. Section
A ends with a table. Sections do not have to start a new page. Section
titles have a keeps/next=1 so they don't get orphaned from section
content. In my problem scenario, section B breaks to page 2 so the
title is not orphaned, which is good. But, section 2 drags with it to
page 2 the last two rows of the table at the end of section 1, leaving a
big gap at the end of page 1 that could easily be filled with those last
two table rows.



I tried a lot of fooling around with keeps on various elements which did
change the output but I could never get the table to separate from the
beginning of section two. Also, if section 1 ends with paras I don't
have this problem. Is there something special with keeps and tables to
look out for?



If anyone has a suggestion of what to try I would be grateful.



Allen Seifert

[ClayHelberg]

Hi Allen-



Yes, I think there is something special about tables that makes them extra
sticky. I recently had an issue where I had a series of tables in a
sequence. Setting any kind of keep on the tables meant that they all stuck
together, overflowing the page. Inserting a dummy non-table block between
tables did the trick for me. Maybe you can solve your problem by adding a
very small empty text block directly after each table.



--Clay



Clay Helberg

Senior Consultant

TerraXML

[steve.thompson4]

Yes, we all know, tables are the spawn of Satan, but...

Have you done a "Resolve" in that last table row's "Modify Element in Context" dialog? Just to be sure there isn't a 'keep' on it that you have forgotten/of which you are unaware.

We've also seen some moderately unstable behavior with tables breaking/not-breaking, but this one is more extreme.

Just a thought,
Steve Thompson
TAD Technical
Boeing-IDS Technical Publications
+1(316)977-0515
MC K83-08
The truth is the truth even if nobody believes it, and a lie is a lie even if everyone believes it.

NOTICE: This communication may contain proprietary or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this e-mail in error, and delete the copy you received. Any and all views expressed are the current understanding of the sender and should not be interpreted as an expression of official Boeing Company policy or position.

Les renseignements contenus dans ce message peuvent être confidentiels. Si vous n'êtes pas le destinataire visé ou une personne autorisée à lui remettre ce courriel, vous êtes par la présente avisé qu'il est strictement interdit d'utiliser, de copier ou de distribuer ce courriel, de dévoiler la teneur de ce message ou de prendre quelque mesure fondée sur l'information contenue. Vous êtes donc prié d'aviser immédiatement l'expéditeur de cette erreur et de détruire ce message sans garder de copie.

[DavidS.Taylor]

If you are using a FOSI, does your e-i-c for the <table> element specify
it is a block element? It appears that the keeps don't know where the
previous element ended and are applying default widow/orphan behaviour
on your table.

Textbreak is a non-inheriting category and needs to be explicitly
specified on every element. I found this out the hard way after
suffering many problems similar to yours.

Cheers,

David


David S. Taylor


Project Manager, Structured Information
Institute for Research in Construction
National Research Council Canada
Bldg. M-23A, Room 239
1200 Montreal Road, Ottawa, ON K1A 0R6

[ebenton]

Or maybe a FOSI pseudo-element usetext.

[ClayHelberg]

Thanks for the clarification, Ed. That's more or less what I had in
mind-something added by the stylesheet during composition, not something
actually included in the document content. I was thinking of it from an
XSL-FO perspective, the context in which it came up for me; my solution was
to generate an extra <fo:block> after each of the generated <fo:table>'s in
the sequence. A pseudo-element usetext would be the FOSI equivalent.



Clay Helberg

Senior Consultant

TerraXML

[ebenton]

Exactly. I don't know about XSL-FO, but in FOSI, the usetext also must
have some content in order for the formatter to apply any formatting to
it. So a pseudo-element would need to have some literal content, at
least a space character between the two backslash literals. "\ \" not
"\\" and not "<pseudo-element>,</pseudo-element>" either.

[berschin]

Benton, Ed L schrieb:
> Exactly. I don’t know about XSL-FO, but in FOSI, the usetext also must
> have some content in order for the formatter to apply any formatting to
> it. So a pseudo-element would need to have some literal content, at
> least a space character between the two backslash literals. “\ \” not
> “\” and not “<pseudo-element>,</pseudo-element>” either.
>

... and sometimes a blank and not even a or other fixed spaces
helps. Had similar problems which only were solved when this block
element contains displayed character. Finally a white 1pt dot helped...


>
> *From:* Clay Helberg [

[margaret.devere]

I had a problem where I needed something for the processor to process,
and finally put in a space character and set the element to Hidden. This
worked and closed up the space quite nicely. My situation was inline.

[ptc-2916524]

Thanks to everyone who contributed to this thread - you helped me think
of how to fix this. Yes, this is a FOSI. I added a usetext after table
which simply outputs a space as Ed describes below. To prevent the
space from adding unwanted horizontal space I set the postspace to -14pt
on the usetext as well as make if break before and after so the
postspace would take effect. Now, items that break to a new page after
a table due to a keeps do not drag along one or more rows from the
table.



Thanks everyone,

Allen