We recently moved from Arbortext 6.0 to Arbortext 7.0 (and had stylesheets converted from FOSI to APP). Writers made extensive use of the _nopagebreak processing instruction in our source DITA files (usually to ensure that text and graphics is kept on the same page).
I was reading the Arbortext 7.0 help, and it appears that _nopagebreak is not support by the APP engine. Does anyone know what an equivalent replacement would be?
Solved! Go to Solution.
Hi Royce
In Styler for APP land virtually everything in my experience is block based so you would normally apply your keep rules on the element objects in the stylesheet and add any extra conditions, contexts or source edit customisation rules there.
However if you cannot define logic for all cases and want a one off inline method for placing between elements keeping 2 unkept blocks together with conditions or rules via a PI you might be best off creating a custom function JS-FOM tag in an associated template (or in Styler in future releases) and apply this via a custom PI e.g. <?A3B2T [nopagebreak]>
It could depend on what you are trying to keep together its context and how thats been configured in APP/Styler.
Regards
Chris
Hi Royce
In Styler for APP land virtually everything in my experience is block based so you would normally apply your keep rules on the element objects in the stylesheet and add any extra conditions, contexts or source edit customisation rules there.
However if you cannot define logic for all cases and want a one off inline method for placing between elements keeping 2 unkept blocks together with conditions or rules via a PI you might be best off creating a custom function JS-FOM tag in an associated template (or in Styler in future releases) and apply this via a custom PI e.g. <?A3B2T [nopagebreak]>
It could depend on what you are trying to keep together its context and how thats been configured in APP/Styler.
Regards
Chris
Chris,
Thanks for the reply. I was afraid that the answer might not be a simple one; otherwise, the processing instruction would not have been removed. I guess I will go back and analyze the writers' use of the _nopagebreak to see if there is a pattern that might be exploitable.