read attribute values of a formatted page while formatting APP

[otudor]

Hi,

How do I capture the value of an attribute of an element on a page while formatting, especially when the element spans over multiple pages?

Basically, I am looking to capture the value of a change attribute(s) found on each page and store it into an array and then display it on the LEP to the corresponding page. I am familiar with store it into an array and then display it.

Thank you in advance!

Have a blessed day!

Florin

[GarethOakes]

I'm going to start with an example scenario: you have a revision-marked document where revision information is stored on attributes of elements. You have an instance of an inserted table that spans over three pages, the table itself has an attribute indicating which revision level the change happened. You need to mark these pages as changed pages in an LoEP. Is this an accurate scenario?

If so, you have two options.

Option 1. Use a counter or Javascript variable to track whether a change is in effect or not (and which revlevel it is at). You can then query this counter/variable at top/bottom of each page to see if a change is rolling over a page boundary. You would have logic in the start-element-tag that captures the first page of the change. Again you would need to use an array variable to mark which pages are changed (where the array index is the sequential page number, if you have fully formatted folios e.g. A-123 then that is an additional concern to consider).

Option 2. Mark the changes at the start-element-tag and at the end-element-tag. You would achieve this by using an array variable where the index is a counter that you increment at each changed element. So the final index is the count of all changed elements you encountered during formatting. At each array index you will then store three values. The first value is the revlevel, the second value is the start page for a change (saved at start-element-tag) and the third value is the end page for the change (saved at the end-element-tag). e.g. [ "r3-12-13", "r2-16-29", "r4-88-100" ]. You then need to process those values wherever you display them.

Both approaches need a double format. First format pass gathers initial page information. Second format pass will then build out the LoEP from the saved array (assuming a longer LoEP section will itself not affect the page foliios).

[otudor]

Hi Gareth,

The scenario is correct.

Let me digest the options and i will get back with eventually more questions or sloved decision.

Thank you for help.

Have a blessed day!

Florin

[otudor]

Hi Gareth,

As always, thank you for your response.

After I digested both options, I do understand the concept of each one, but Option 2 looks much more elegant to me, although Option 1 is viable too.

To be able to implement Option 2 I need to better understand how to “mark the changes”, and what do you refer to by start-element-tag and end-element-tag?

1. How to mark the changes? Do I use certain attributes and values? If so how would I mark an end-element-tag?
2. Start-element-tag and end-element-tag. By these terms are you referring to the XML elements in the document?

The “how to mark the changes?” question begs another question of which I could not find the answer in the Styler/APP Help manual, namely is the formatting process traversing the entire XML tree of the document, element by element, regardless if there is a formatting instruction or not on elements? If yes, what kind of traversing is used?

Initially, my idea was to capture each formatted page and put its XML content into a stream or a string variable and then if it is a valid XML chunk put it into a XML DOM and look for the changes and pick the latest change on the page and put it into an array where the index would be the page number; if the XML is invalid then I would do the hard work of parsing it.

I had problem getting the XML content of the page/block/layer into a stream and then read the stream. Any idea how to do that?

Thank you for help.

Have a blessed day!

Florin

[GarethOakes]

1. The marking of changes would be via the array variable.

2. Yes. You can use edited source to control behaviour at start/end of each element.

The formatting process is quite interesting. Basically APP starts at character position 0 and works its way through the content. It keeps track of the DOM as it formats so you can use XPath etc. I think newer versions may also support format-by-DOM but it is essentially a depth-first traversal.

For your other approach of parsing the XML, APP actually has an interesting couple of features you may find useful. One is a Javascript printer driver, the other is an XML print driver. Both of these work as if they are a print driver (e.g. they "see" the page in its final formatted form with hyphenation). You end up with a print-centric XML format (or set of Javascript events) that you can parse to determine certain information and yes this could work for LoEP. I think it would be more effort to implement than my Option 2, but it would be a much more flexible system.

The final method that comes to mind is "tree augmentation". You could store page information as DOM augmentation during formatting, then query it at your LoEP element to build the required list of changes.