Thanks for the clarifications, Bob. I have used
element_or_condition_name_change_bar_start.txt and
element_or_condition_name_change_bar_end.txt in other instances, so I
understand that technique.
The root of my problem appears to result from the fact that I do not test
for touchup and explicitly call out chgmark at the e-i-c of any element.
The *only* chgmark I emit anywhere is from the e-i-c for touchup itself.
(We used to support change highlighting withing change bars, so that's how
I know it requires a system-func to detect touchup in context="* touchup".)
I was initially expecting that the composition engine would resolve the
float output as being in context of touchup since it is called from (and,
frankly, emitted in ... it appears to me) context of touchup. However, this
"lack" of context is true even when the entire h2 owning the table that
breaks across pages is wrapped by touchup tags. (So the gap is not the
result of only having change bars on the header text, not the row ... my
entire table is wrapped ... but in the XML content, not in my stylesheet
... and if I look closely at the output ... it appears as though the change
bar starts after the initial rule of the table header on the second page of
the table. So I now conclude that floats are "outside" the normal flow /
context at least as far as the touchup PI is concerned.
Here is an example XML psuedo-instance:
...
<h2>
<title>my h2 title</title>
<para>...</para>
<table>
<title>my table title</title>
...tgroup/colspecs/thead/tbody all go here
</table>
<para>...</para>
<newpage/>
<para>...</para>
</h2>
...
The resulting change bar is completely solid on page 1 beginning with the
title of the h2 and continuing to the last rule of the last row of the
table that fits on the page. On page 2 the change bar begins, it appears,
AFTER the first rule of the table header ... which is well after the table
title continuation ... the piece that floated. If I force a change bar on
the floated information, there is a gap after the baseline of the table
title continuation until just after the first rule of the table header.
On page 2, the change bar, once it starts is continuous to the baseline
after the post-table paragraph.
On page 3, the change bar continuously marks the post-newpage paragraph.
With the exception of the "force" test of chgmark on the float, all of this
is achieved, stylesheet-wise, by the previously included excerpts. The
<att> that floats. And the e-i-c for touchup.
Out of the box Editor change tracking, converted by an ACL to touchup PI
markup (and another ACL to remove it), controls the change bar from an
authoring perspective.
On Thu, Jan 12, 2012 at 11:31 AM, Bob Spangenburg <
-> wrote:
> Paul,
>
> The content of your varaible ??????"table-title.txt" would contain the
> begining and end of your change bar markup, in your case, the PI. In all
> the code I use, I have two variables: "scontent.txt" and "econtent.txt".
> These two variables are normally a null. When change bars are needed, they
> get filled at the e-i-c, with the change mark up if it is applicable.
>
> However, in your case, if the title element already has the markup in the
> content of the <title> tag, it should be passed along to the float. The
> markup you're using (PI's) should then, using their own e-i-c, trigger
> change bars. I'd have to play with it to see why you're not getting them,
> since I think you mentioned early on that you were getting the bars on the
> first title.
>
> Let me know and I'll see if I can get a 'non-CPD' version working to show
> this.
>
> Oh, to your note about the gap... most likely, you're getting it because
> you're showing the bar on the content of the header row, not the row
> itself. When change bars are "joined," they have to be adjacent elements.
> There is a difference between marking the content of the row and the row
> itself. When multiple rows are added or deleted and marked, they'll show a
> solid change bar. If the content of the sames rows are deleted, but the row
> is left in tact, you'll get broken change bars.
>
> HTH,
>
> Bob
>
