Building tables as generated text from save/usetexts - page breaks?

[JasonBuss]

Ok, so I have a series of small output docs (three elements within a wrapper, all wrapped in a root element) that I print in tabulated form.

I have these values aggregating into a savetext that eventually outputs a table as part of a usetext at the end of the document.

Since upgrading from 5.3 to 5.4, I have come to find that if the amount of content is more than a page-full, my table no longer breaks to another page (runs through the footer and throws my favorite error, page overset fault).

Has anyone else had this issue? Any clues here?

I have checked all the e-i-cs for table markup, for the document elements themselves, and the pseudo-element used to generate the text, and I have no explicit keeps set anywhere. I'm just at a loss as to what might have happened. I know I'm not the only one building tables in gentext, so perhaps someone else has seen something?

Thanks,

-Jason

[ClayHelberg]

Hi Jason--



Have you tried fiddling with the deepcontentsplitting preference? IIRC,
between 5.3 and 5.4 was about the time they either added or
significantly improved that feature.



--Clay





Clay Helberg

Senior Consultant

TerraXML

[JasonBuss]

Yup, gave that a shot, no luck with any of the three settings in 5.4

It just acts like it's "stuck". There isn't one setting I have been able to adjust that makes any impact on the pagination of this generated table.

[ptc-1908075]

Hi Jason,

This still sounds like a deep content splitting issue, like something changed from 5.3 to 5.4. The release notes might have info.I have attached PDF on the subject from my book in hopes it might help. Note that itis based on 5.3.

Please keep us posted on this.

Good luck!
Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"

[GarethOakes]

Time to try out APP ? 🙂

[naglists]

Do you have a <thead> in the generated table? Try removing that.

I haven't nailed it down 100% yet, but in our migration from 5.3 to 6.0 I
have discovered some generated tables that will not break if I use a
<thead>.

Technically, if I strip all the contents of the thead e-i-c, it will still
publish correctly. It's when I start adding back the formatting it fails.
If I'm remembering correctly, it was <font... in=" thead's=" e-i-c.=" but=" i=" could<br="/>be wrong. I think I wrote about it here ... in how much detail and when
relative to my testing so far, I can't recall.

[ebenton]

If that works, you could still use < e-i-c gi="row" context="table" occur="first"> for a row with header-like formatting. You would miss the default header floating behavior for multi-page tables, but...

[JasonBuss]

Wow, that was it. What the flip? That seems pretty random...

Have you reported it to Arbortext?

Thanks, BTW. I would have spent waaaay too much more time on this before finding that (If I did at all).

[naglists]

I have not reported it yet. I've been buried w/other issues ... hopefully
those'll settle down this week and I'll be able to refine it to the point
of case submission. I got pretty close before getting distracted.

[naglists]

I now have a case open against 6.0 m010 for this. Not sure what I was
seeing earlier, but a thead in a generated tables prevents the table from
breaking across pages: Modifying or removing the thead e-i-c has no impact.

[naglists]

Bizarre discovery. I was seeing inconsistent breaking / non-breaking
behavior on these tables and independent of the thead in the generated
tables in the FOSI and I discovered some markup that will occasionally
cause different behavior. In the examples below, <testing_summary_anchor>
is the tag that pulls in the generated table that will (sometimes) not
break across pages.

For example, this will not break:
<h1 landscape="yes">
<title>testsumm</title>
<anchors>
<testing_summary_anchor>
<title>Testing Summary</title>
</testing_summary_anchor>
</anchors>
</h1>

This WILL break:
<h1 landscape="yes">
<title>testsumm</title>
<anchors>
<testing_summary_anchor>
<title>Testing Summary</title>
</testing_summary_anchor>
</anchors>
</h1>
<h1>
<title>More random stuff</title>
<para>paragraph</para>
<para>Lorem ipsum dolor sit amet.</para>
<para>Etiam sollicitudin posuere nisi. Sed id dolor.</para>
</h1>

I think I ran a test with just a:
<para></para>

After the closing </anchors> and changed the break / no-break behavior.

Now I'm suspecting keeps logic has changed somewhere in the core code. Does
anyone remember anything about keep behavior changing anywhere in the 5.4
or 6.0 code base?

[ebenton]

We moved from 5.2 to 6.0 and have noticed keeps behavior differences in PDF output using Print Composer. We have some baseline documents with tables that with 5.2 would produce PDF that would start on the bottom of a page and display one or two rows. With 6.0 these same documents get rendered with the table beginning on the next page. Nothing we change about keeps formatting in the FOSI will change this behavior.

[naglists]

Thanks, Ed, good to know.

[DavidS.Taylor]

Paul,

If you haven't seen the following before, perhaps this information is of interest...

From the 5.4 Release Notes (F000):

"The widow count (widowct) and orphan count (orphanct) for keeps now
accept values up to 7. Widow count and orphan count can also be used to group
rows together within a tgroup. Table header rows are excluded from the count." (my underline)

The second is from the Help Center in M080, in reference to widows and orphans:

"If a page or column break occurs in the middle of a table<,">http://127.0.0.1:60057/stylerHelp/help6011.html?queryId=138e88cda6c>, each table<">http://127.0.0.1:60057/stylerHelp/help6011.html?queryId=138e88cda6c> row is considered as a line. When you make settings in the Number of lines to keep at top of page or column or Number of lines to keep at bottom of page or column fields in the context of table<">http://127.0.0.1:60057/stylerHelp/help6011.html?queryId=138e88cda6c> these define the number of table<">http://127.0.0.1:60057/stylerHelp/help6011.html?queryId=138e88cda6c> rows to control. Widow<">http://127.0.0.1:60057/stylerHelp/help6011.html?queryId=138e88cda6c> and orphan control will work correctly within a table<">http://127.0.0.1:60057/stylerHelp/help6011.html?queryId=138e88cda6c> that breaks over pages."

It's interesting that widowct and orphanct are operating on the rows of the table, and that table header rows are excluded. This may be an indication of why removing <thead> affects the page break, though it doesn't necessarily indicate whether there is a bug or not. Spanning table cells vertically also determines where column/page breaks can occur when deepcontentsplitting is off; how this and keeps interact is not clear.

Are you able to determine what the resolved characteristic values are in the keeps category for the e-i-c's following the inserted table?

I haven't set up 6.0 yet, so I don't if there were further changes from 5.4.

David

David S. Taylor

Project Manager, Production and Marketing
Codes and Evaluations | NRC Construction Portfolio
National Research Council Canada
Building M-23A, Room 239 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
Telephone: +1.613.990.2731 | Fax: +1.613.952.4040
David.S.Taylor@nrc-cnrc.gc.ca<">mailto:David.S.Taylor@nrc-cnrc.gc.ca>

[tbihlmeyer]

I just had a case open with PTC and we found that linking was causing an issue in my tables. We took linking off the row and the tables then broke just fine. You might try exploring something there.

[naglists]

Hi Trudy,
You beat support to the punch.

The way we have implemented linking from some of our generated tables is
wrapping the entire table with a <_link> somewhere in the background.
Support thinks if the linking is rewritten at the row level and not the
entire table (haven't dug deeper yet, so this isn't 100% clear to me yet)
linking might still work without changing the keeps behavior. That said,
support also thinks the way linking is working now should be "random" as
far as taking a reader to the right location which doesn't make sense. I'm
pretty sure our readers use this feature and have not reported random
linking as an issue.

Jason: Are/were you linking from your generated table?

[JasonBuss]

And therein lies the rub. My table used no linking whatsoever. Just built a table with a <thead>, then rows in the <tbody> wrapped in a pseudoelement.

Removing the <thead> and applying a pseudoelement to the first row only in that context was what allowed my table to break correctly again.

I can't tell if there's more than one culprit here, or something more in the underlying structure (or the context that the structure appears within) that causes the problem.

[naglists]

My problem has been resolved.

It turns out that when a text variable is declared a hotlink this causes
<_link> markup to wrap that variable bringing a keep condition. (That is
more or less a repeat of support's explanation.)

Practically speaking this meant that I had to change the way that I saved
content for publishing in generated tables.

Originally I was appending rows to a hotlinked text variable that I then
called between the tbody tags of a generated table.

For example:
<stringdecl textid="all_your_rows_are_belong_to_us.app" status="1"&lt;br"/>hotlink="1">

I tried fixing this by changing it to
<stringdecl textid="all_your_rows_are_belong_to_us.app" status="1"&lt;br"/>hotlink="0">

And storing each row in a variable before appending it to the all rows
variable. For example, I would have had:
<stringdecl textid="one_row.app" status="0" hotlink="1">
<stringdecl textid="all_your_rows_are_belong_to_us.app" status="1"&lt;br"/>hotlink="0">
and
<savetext textid="one_row.app" conrule="[MY" row=" content=" goes<br="/>HERE]"placemnt="after" append="0">
<savetext textid="all_your_rows_are_belong_to_us.app"&lt;br"/>conrule="one_row.app"placemnt="after" append="1">

But that didn't work.

In the end, I had to save each cell's contents to a variable declared like
this:
<stringdecl textid="cell_1.txt" status="0" hotlink="1">

Then I would save cell_1.txt into my all rows variable which I again
ultimately called from between the tbody element in a generated table.

P.S. I didn't pursue with support WHEN this change occurred but it seems
likely, based on Jason's experience (unless his problem stems from a
different cause), somewhere after the 5.3 m110 release but before whatever
5.4 release Jason is in. My fix works in 6.10 m010.