Skip to main content
Known Participant
June 19, 2008
Question

Last Paragraph rule broken?

  • June 19, 2008
  • 8 replies
  • 743 views
FrameMaker 7.2p158, Windows XP SP2, 2GB RAM

Hello Forum,

I'm having a bad hair day with last paragraph rules. If you have an element which allows text containers and marker elements, last paragraph rules work in a surprising way if the last element is not a paragraph.

Consider the following EDD:

Element (Container): HLE
General rule: Chunk+
Valid as the highest-level element.

Element (Container): Chunk
General rule: (Para | Marker)+
Format rules for last paragraph in element
In all contexts.
Default font properties
Color: Red

Element (Container): Para
General rule: <TEXT>

Element (Marker): Marker
Initial marker type
In all contexts.
Use marker type: MyMarker


... and a simple test document using the above element definitions (using [ and ] instead of < and >):
[HLE]
[Chunk]
[Para]asdf[/Para]
[Para]asdf[/Para]
[Marker /]
[/Chunk]
[/HLE]


I would expect the second [Para] (as the last paragraph in the parent element) to format as red text. However, it does not, and formats as an ordinary para. I can find nothing in the SADG to back this behaviour up, and I am a bit confused. It seems that Last Paragraph rules might better be named Last Element rules if they do not necessarily affect the last paragraph.

Background: I'm trying to use markers to represent deleted content, hoping that the use of markers instead of empty container elements will allow me to maintain the page layout without awkward gaps. Since I use Last Paragraph rules quite a lot in my EDD, and the Last Paragraph rules do not work in the way I expected, this is proving difficult. Instead, I'm having to use a container element [Deleted] for deleted content, with context rules on various other elements to format them as run-in headings if {before Deleted}. This is inelegant and error-prone.

I'd appreciate any suggestions or comments.

Thanks,

Jon

[edited: caught out by < and > again.]
This topic has been closed for replies.

8 replies

J_D_WAuthor
Known Participant
June 28, 2008
Lynne,

That second solution of yours is ingenious! I don't think I'd be able to implement it as it wouldn't fit very well into the workflow; however, it's given me another idea which would allow me to revert back to using a marker element.

I'm going to try using FrameSLT to look for a [Marker] after a [Para], set an attribute on the [Para] and then delete the [Marker]. Then I could use my planned EDD rules to format the element the way I want. For our workflow, it doesn't matter if the deleted content is directly represented in the structure, as long as the formatting indicates that content has been removed.

If you hadn't mentioned XSLT in your alternative solution, I probably wouldn't have thought of using FrameSLT, so thanks!

Jon
Inspiring
June 24, 2008
Jon,

Even though the WYSIWYG environment is one of the major reasons to use FM, it does enforce restrictions on the context specifications that are practical. If it were possible to test an arbitrary sibling instead of just the immediately preceding and immediately following ones, then each change of an element or attribute could trigger reformatting of very large portions of a document and performance would be unacceptably slow. Hence FM does not allow the kind of testing you want.

The run-in head approach that you now plan was one of two I would have suggested as an alternative. I cringe a bit at the other one, because it is not WYSIWYG. Also, I don't know if it fits into the environment in which these documents will be used. The idea is to have two forms of each document, an editing form and a publishing form. Users edit the document, unsurprisingly, using the editing form which makes no attempt to turn the last paragraph red. As each draft is complete, the user saves the document as XML, using an application that runs XSLT to set an attribute on those paragraphs that should be red. XSLT does not have the same performance restrictions as FM; it has no need to keep up with real-time manipulations of the document. Furthermore, it is straightforward to do the kind of testing you need in XSLT. The XSLT output is the XML version of the publishing form of the document. Opening this XML document back in FrameMaker will trigger the desired formatting from the attribute value. You could use the FDK or FrameScript to automate the save and re-open. If you do, you can have some naming convention that derives the filename of the publishing form from that of the original document and even makes it read-only to prevent the user from accidentally editing the wrong version of the file.

--Lynne

J_D_WAuthor
Known Participant
June 23, 2008
Hi Lynne,

Unfortunately I can't use a {before Marker} type of rule, because the marker element can appear anywhere within [Chunk], and the formatting needs to be on the last subelement of [Chunk]. The EDD I posted was only an example, but the actual EDD is far more complex. In the real EDD, a typical case would be an element called [ListItem] which has a last paragraph rule to add extra space between consecutive [ListItem]s. It's a shame that I can't use something like {before Marker{last}} as that would fix it!

What I've decided to do is to make [Marker] a container, and put context rules on the dozen or so elements that are valid in the same place as [Marker] and adjust the formatting as appropriate if they are followed by [Marker] - usually by making them into run in headings. This will minimise the amount of reworking I'd have to do (I hope).

Thanks to yourself and Van for the suggestions.

Jon
Inspiring
June 20, 2008
Jon,



Can you get the desired formatting if you replace the all-contexts rule on Chunk with a context rule on Para that tests for the context "{before Marker}"?


FYI, FM 8 behaves the same way in this regard as previous versions.


First and last paragraph rules apply to the first or last content in an element when that content consists of a FrameMaker paragraph. It would be misleading to call them "first/last element rules" instead because this content need not be in an element. Suppose, for example, that a list item can contain an example surrounded by text. The result might be three paragraphs within the item, but only one subelement. Besides, as you've noted, the rule won't apply to the last element if that element is not a paragraph.



--Lynne

J_D_WAuthor
Known Participant
June 20, 2008
Van,

I read that section of the SADG too before posting originally and I agree with you that FrameMaker may simply be treating the marker as a text range and therefore not applying the formatting.

What I'm really trying to do is to replicate the behaviour of 'automatic change bars' in a structured environment. I control change bars via the EDD based on the value in an attribute on each paragraph that represents the revision number of the paragraph. The deleted elements are there so that I can put in a rule that looks to see if an element is followed by [Deleted] and put a change bar on the paragraph before the deleted text. I thought it would be straightforward, but no...

Thanks for the help though; maybe I'll figure out how to do this another way. Sadly I can't use conditional text as I am already using it for filtering via ABCM.

Thanks,

Jon
Known Participant
June 19, 2008
Jon,

The Structure Application Guide does seem to imply the behavior you discovered about markers as the last element. It states that if the last child element is formatted as a text range, then the last paragraph format rules are ignored. As you said, marker elements cannot be formatted as either text or paragraphs, but maybe FrameMaker assumes they are text because in most cases markers are inserted into text.

You can always consider updating to FrameMaker 8, which allows you to filter by attribute. You could create a container element named Deleted and give it an attribute with some value. Then filter the content to exclude elements with that value of that attribute, then Frame should hide those elements the same way as it does with conditional text. The downside would be that you cannot use conditional text at the same time.

Hope this helps,
Van
J_D_WAuthor
Known Participant
June 19, 2008
Hi Van,

Thanks for your response. The problem is that marker elements don't have any text formatting rules. The only properties that can be set for markers are context labels and marker type. All the other properties are off-limits.

Thanks for the suggestion though.

All the best,

Jon
Known Participant
June 19, 2008
Jon,

Just a thought; I have not tested this, so it is just a guess.

Try adding an all contexts formatting rule to your marker element and specify that it is text range formatting, but specify nothing more than that. This may force Frame to think of this element as text, not a paragraph, which may be the default behavior.

Hope this works,
Van