savetext/usetext not respecting/eating nested touchup PIs
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.
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."
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.
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.
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.
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 ...