table rows using Styler stylesheet not breaking as expected

[naglists]

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

[naglists]

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
>
>
>
>
>

[dcarney]

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

[naglists]

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 <->

[naglists]

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