savetext/usetext not respecting/eating nested touchup PIs

[naglists]

Does this sound familiar to anyone?

I have code that will convert change tracking into touchup PIs for rendering
in PDF as change bars. My code and FOSI treat nested touchup PIs as a second
layer of change and highlight the text double-nested with a yellow
background. This code is working fine in most areas of our documents. An
author just reported, and I have confirmed, that this is failing inside of
elements that are parts of semantic tables. It appears that savetext'ing the
nested touchups and usetext'ing them somehow renders one layer invisible to
the FOSI or is "eating" one set. I still get the change bars in the PDF next
to my semantic table output, but I do not get the highlighting on what
should be nexted touchups.

Gesundheit! I know. Tables. Spawn. Semantic Tables. Spawn of spawn.

Has anyone else run across this?

--
Paul Nagai

[jkaplansky]

Vaguely familiar. Are you using ?_cellfont PIs or ?font PIs to get the
highlighting? If you're using ?font PIs, try generating ?_cellfont PIs
instead. Tables have their own particular set of PIs, and might respect
a generated table PI where regular PIs don't necessarily "take."



Hope this helps.



-Jean Kaplansky

[naglists]

Hi Jean,
Thanks for the thought. I did test some changes to my FOSI which would allow
me to use cellfont PIs but to do so would require a fair amount of recoding.
For what it's worth, my code works just fine in normal tables. This is what
makes me suspicious of the savetext/usetext. It is the only difference
between a normal table and a semantic table I can see.

I am accepting change tracking and wrapping the change in attr="1"?>. A second change, inside of that markup would
get a nested . So a complete
change might look something like this:

<para>This is a new sentenceattr="1"?> with a new word.
</para>

"with a new word" being the second, layered change. I don't know whether my
highlighting will reach through e-mail systems or not, but the output would
look like this:

This is a new sentence with a new word.

And it would have a change bar on the outside of the page.

[jkaplansky]

The thing about tables is that even though you can control a lot of
things with a FOSI, they still have their own set of PIs for formatting,
and I know that those work through savetext/usetext (at least with
regard to row height stuff), since I know someone who had to do that the
other day...



I've noticed that sometimes what doesn't work from a FOSI in a table, or
from regular PIs in a FOSI in a table, does work when you change it to
table PIs...



I assume the PIs you're showing below are pseudo-code, and what you've
really got in the FOSI is something like this:

? I can see why you'd prefer to
do this rather than use the _cellfont PI which is a singleton. Have you
tried using the this one: ..../_font> instead of ?



If you've tried all of the above, then you may want to see if you can
get some input from Tech Support.



-Jean K.

[naglists]

Hi Jean,

It's not pseudo code. Our change tracking code inserts the pub touchup PIs.
The FOSI formats a single touchup as a change bar. A nested touchup is
highlighted. This code works for "normal" elements as well as tables but
fails (the highlighting only ... we are getting the change bar) in semantic
tables only. I am in the process of opening a call w/support.

[tbihlmeyer]

Paul,

This is straining what few brain cells I have left...but, I seem to recall that the PI was defined in your fosi. Did you try adding another e-i-c for the PI in the context of the original PI?

so, would it help to have an e-i-c touchup * touchup?

Its just a thought.
Trudy

[naglists]

For some reason e-i-c's for PIs (at least the touchup PI) do not know about
context of another touchup PI. I'm not sure if it is the first touchup can't
know it's ancestors or whether it's not possible for any element to know
it's in a touchup (there is a distinction there, but I'm not positive I've
'splained it English-like). One of them fails. In other words, gi="touchup"
context="* touchup" fails even when that is, in fact, the actual context.

My e-i-c actually relies on an attribute test that runs a system-func that
reports whether or not touchup has an ancestor touchup. Why the ACL can
figure it out but FOSI can't, I don't know. Anyhow, this works, as I've
said, everywhere (we've tested) except the semantic table.

Thanks, Trudy and Jean, for taking some time to think on this.

I'll be sure and let everyone know what support and I eventually find ...