Skip to main content
A
Anonymous
July 25, 2012
Question

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

  • July 25, 2012
  • 17 replies
  • 2996 views
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

    17 replies

    Show previous replies
    E
    ebenton1-Visitor
    1-Visitor
    August 2, 2012
    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.
    N
    naglists1-Visitor
    1-Visitor
    August 2, 2012
    Thanks, Ed, good to know.

    D
    DavidS.Taylor1-Visitor
    1-Visitor
    August 2, 2012
    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>


    T
    tbihlmeyer1-Visitor
    1-Visitor
    August 3, 2012
    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.

    N
    naglists1-Visitor
    1-Visitor
    August 6, 2012
    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?

    A
    Anonymous
    August 6, 2012
    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.
    N
    naglists1-Visitor
    1-Visitor
    August 8, 2012
    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.


    Terms & ConditionsAccessibility statement