Skip to main content
N
naglists1-Visitor
1-Visitor
January 14, 2015
Question

table rows using Styler stylesheet not breaking as expected

  • January 14, 2015
  • 4 replies
  • 1310 views
6.0 m090.

Hi. I have a CALS/OASIS table consisting of three almost-page-length rows
(two columns wide). In each of my two Styler environments, the table
doesn't break. It overruns the page. In at least one of my FOSI
environments, it breaks as expected, producing a three-page, continued
table.

I have Edited Source on all of the table components of the Styler
stylesheets (not to change them, just to SEE the FOSI coding) but I can't
see anything that suggests a difference in breaking rows. Keeps, for
example, are all Derive/Derive/No/No/No on tgroup, tbody, row.

Any thoughts about how Styler might think about tables differently?

deepcontentsplitting is off for us, but turning it on doesn't change this
behavior.

If I insert an empty 0.01mm high row between each of the real rows, then
the table appears to break as expected which is to say it looks right in
the PDF (viewed onscreen). I don't know if the blank rows are ending or
leading the pages.

--
Paul Nagai

    4 replies

    N
    naglists1-VisitorAuthor
    1-Visitor
    January 14, 2015
    Nevermind. It is deepcontentsplitting. Looks like I'm turning it back on.

    On Wed, Jan 14, 2015 at 11:56 AM, Paul Nagai <->
    wrote:

    > 6.0 m090.
    >
    > Hi. I have a CALS/OASIS table consisting of three almost-page-length rows
    > (two columns wide). In each of my two Styler environments, the table
    > doesn't break. It overruns the page. In at least one of my FOSI
    > environments, it breaks as expected, producing a three-page, continued
    > table.
    >
    > I have Edited Source on all of the table components of the Styler
    > stylesheets (not to change them, just to SEE the FOSI coding) but I can't
    > see anything that suggests a difference in breaking rows. Keeps, for
    > example, are all Derive/Derive/No/No/No on tgroup, tbody, row.
    >
    > Any thoughts about how Styler might think about tables differently?
    >
    > deepcontentsplitting is off for us, but turning it on doesn't change this
    > behavior.
    >
    > If I insert an empty 0.01mm high row between each of the real rows, then
    > the table appears to break as expected which is to say it looks right in
    > the PDF (viewed onscreen). I don't know if the blank rows are ending or
    > leading the pages.
    >
    > --
    > Paul Nagai
    >
    >
    >
    >
    >
    D
    dcarney8-Gravel
    8-Gravel
    January 14, 2015
    Paul,

    One thought: you mention checking that Keeps are fine on tgroup, tbody,
    and row, but you should also verify them for the entry element.

    If your edited source has not been changed by you in any way, it seems
    like it would make sense to remove it. My understanding (possibly
    mistaken?) is that it is somewhat dangerous to have edited source, since
    changes elsewhere in the style sheet might cause the edited source to be
    "out of date". Do others have an opinion on this?

    We have definitely seen Styler issues/bugs with tables that span multiple
    pages; if I were you, after doing due diligence to make sure my stylesheet
    wasn't to blame, I'd report this to PTC.

    Dennis


    N
    naglists1-VisitorAuthor
    1-Visitor
    January 14, 2015
    Thanks, Dennis.

    Yes, I was trying to chase Keeps into the Edited Source. And yes, I agree,
    it is definitely a best practice to use as little Edited Source as
    possible. I didn't actually have Edited Source on table, tgroup, tbody, or
    row (I didn't go down to the entry level) and I wasn't actually creating
    and saving any. I did, however, use it to just be able to see how Styler
    menus are translated into FOSI coding on those particular elements because
    I had exhausted other avenues of research ...

    It turned out to be a change in the behavior of deepcontentsplitting
    between 6.0 m010 and m090. I'm not sure why I am only finding out about
    this now, since we rolled out 6.0 m090 quite a while ago. We do have some
    authors who prefer to craft sometimes creative solutions rather than report
    problems or seek guidance, so I'm wondering if we now have a lot of tables
    where page breaks are manually managed.

    Ironically, my notes in the ACL where we set deepcontentsplitting indicate
    we turned it off when deploying m010 due to undesirable behavior introduced
    at that time. Wonder if m090 fixed something what broke in m010 or if m090
    is now broken?

    In either case, it does seem odd to me that deepcontentsplitting would
    prevent a row from breaking to the next page that clearly does not have
    room to fit. To be clear, the page break is failing to be inserted between
    rows. This is not a row itself being split across pages. Maybe that is
    worth reporting ...

    Anyhow, letting deepcontentsplitting default to on instead of forcing it
    off has resolved the table problem I was facing this morning, so my
    immediate problem is resolved.


    On Wed, Jan 14, 2015 at 12:51 PM, Dennis Carney <->
    N
    naglists1-VisitorAuthor
    1-Visitor
    January 19, 2015
    I should have posted a screen cap of the tgroup Keep properties tab. A
    styler guru would have seen the rookie (or FOSI coder) mistake immediately.
    Support got me there with this guidance:

    Open the style sheet in Styler and locate the tgroup element and then
    highlight the context "first group". Select the Breaks tab and then select
    the Keeps button. At the top of the dialog set the values to Any number for
    the widow and orphan control setting for both the top and bottom of the
    page.

    Editing source as FOSI was my attempt to try and see how/where keeps were
    being set. I still don't know. But "Any Number" vs. "Derive" solved my
    table overrun problem.


    On Wed, Jan 14, 2015 at 1:41 PM, Paul Nagai <->
    wrote:

    > Thanks, Dennis.
    >
    > Yes, I was trying to chase Keeps into the Edited Source. And yes, I agree,
    > it is definitely a best practice to use as little Edited Source as
    > possible. I didn't actually have Edited Source on table, tgroup, tbody, or
    > row (I didn't go down to the entry level) and I wasn't actually creating
    > and saving any. I did, however, use it to just be able to see how Styler
    > menus are translated into FOSI coding on those particular elements because
    > I had exhausted other avenues of research ...
    >
    > It turned out to be a change in the behavior of deepcontentsplitting
    > between 6.0 m010 and m090. I'm not sure why I am only finding out about
    > this now, since we rolled out 6.0 m090 quite a while ago. We do have some
    > authors who prefer to craft sometimes creative solutions rather than report
    > problems or seek guidance, so I'm wondering if we now have a lot of tables
    > where page breaks are manually managed.
    >
    > Ironically, my notes in the ACL where we set deepcontentsplitting indicate
    > we turned it off when deploying m010 due to undesirable behavior introduced
    > at that time. Wonder if m090 fixed something what broke in m010 or if m090
    > is now broken?
    >
    > In either case, it does seem odd to me that deepcontentsplitting would
    > prevent a row from breaking to the next page that clearly does not have
    > room to fit. To be clear, the page break is failing to be inserted between
    > rows. This is not a row itself being split across pages. Maybe that is
    > worth reporting ...
    >
    > Anyhow, letting deepcontentsplitting default to on instead of forcing it
    > off has resolved the table problem I was facing this morning, so my
    > immediate problem is resolved.
    >
    >
    > On Wed, Jan 14, 2015 at 12:51 PM, Dennis Carney <-<br/>> > wrote:
    >
    >> Paul,
    >>
    >> One thought: you mention checking that Keeps are fine on tgroup, tbody,
    >> and row, but you should also verify them for the entry element.
    >>
    >> If your edited source has not been changed by you in any way, it seems
    >> like it would make sense to remove it. My understanding (possibly
    >> mistaken?) is that it is somewhat dangerous to have edited source, since
    >> changes elsewhere in the style sheet might cause the edited source to be
    >> "out of date". Do others have an opinion on this?
    >>
    >> We have definitely seen Styler issues/bugs with tables that span multiple
    >> pages; if I were you, after doing due diligence to make sure my stylesheet
    >> wasn't to blame, I'd report this to PTC.
    >>
    >> Dennis
    >>
    >>
    >>
    >> From: Paul Nagai <->
    >> To: -
    >> Date: 01/14/2015 12:56 PM
    >> Subject: [adepters] - table rows using Styler stylesheet not
    >> breaking as expected
    Terms & ConditionsCookie settingsAccessibility statement