FrameMaker 10 font size autonumbered xml lists on import to FM

[Guest]

I have a bizzare problem using Structured FrameMaker 10.

When importing xml documents, I have a set of Procedures which are broken down into numbered Steps, each with their own para.  So the tree would look like this:

section

     para

          Procedure

               Step

                    para

The numbering is described correctly in the EDD, with Step having a default font size of 11pt; this numbering works.

Given that I have several sections with several para/Procedure/Step/para contents, the first, say, two or three groups display the Step number in the required font size (11pt).  But thereafter the remainder have resized to 14pt.

The supporting para text in all cases is 11pt, which is what it should be.

The only thing I have at 14pt in my EDD is a section 2 title, but in most cases there is an intervening para which displays correctly at 11pt, so it does not look like an inheritance problem.

In Structured FrameMaker working on its own (with no xml import) this isn't a problem.

Has anyone seen anything like when trying to import xml, and more to the point, put a stop to this weird behaviour?

[Van Kurtz]

Chris,

First, I am not sure you mean what your structure implies. To me, it looks as if the Procedure element is inside a para element, which is inside a section element. I am guessing that you really mean it to be:

section

     para

     Procedure

          Step

               para

Second, given the above, I am guessing the title element for the section fits in the structure as:

section

     title

     para

     Procedure

          Step

               para

If the above is indeed what you want to do, then I would have the EDD set the general font size (11 pt) in the section element; all elements contained within section and their children will have a font size equal to 11 pt. And then you need to set the font size ONLY in elements that you do not want to be 11 pt. In your case, the title element should set its font size to 14 pt; none of the elements following the title element will be at 14 pt, because they are not contained with the title element.

Formatting is governed by containment/inheritance, not order within the document.

Van

[Guest]

Van,

I saw your reply a couple of days ago but there was no "Reply" button available, hence the delay (I replied to the e-mail but as it has a no-reply indicator in the address, so I'm guessing that went straight down the toilet).

In sum, here's what I said.

I left out the "title" element (fat fingers), but the structure was as I described it.   The XML input requires that "Procedure" be legal for both a "section" or a "para"; for the most part it follows a para, which introduces the "Procedure" and its contents.

I like your suggestion about a setting of 11pt at "section" level, but I already have it at "chapter" and "para" so I'm guessing it should be covered.

I found a really silly solution (one off, I hasten to add) and that was to select the whole "chapter", set the font size for everything to 11pt and then re-import the EDD.

I've subsequently found that by setting "Step" at 11pt solved the problem - although this is really not the way FrameMaker describes inheritence, and considering that it worked properly for half of my document and then fell over for the other half, it's still a bit odd.   My fix, if somewhat overdoing things, does work.

Thanks again for your help; back to cross-references - what a joy!

Regards

Chris

[Van Kurtz]

Chris,

I like your suggestion about a setting of 11pt at "section" level, but I already have it at "chapter" and "para" so I'm guessing it should be covered.

The point is to set the font and its size in the root element of the document, whatever it might be. With NO other changes, all the children of the root element inherit the font size. Then change only those elements, such as the title element, that you want to be different. The only time you should need to set OTHER elements to 11pt is in the children of those elements that have font changes, likely a very rare case.

I like the EDD to control all the formatting. So, I avoid overrides completely. To make sure that I do not accidentally make an override, I periodically reimport the EDD with remove overrides checked (or whatever the option is in the dialog box). This makes sure the EDD formats are applied completely.

In your original post, you said that some steps are at 11 pt and some at 14 pt. I am suggesting that maybe an override was applied at some point. Reimporting the EDD without removing overrides makes it look as if something is wrong with the EDD. To make sure the EDD is working as expected, import the EDD with overrides removed. If the problem still exists, then you need to look very carefully at your EDD to make sure it is working as you want.

Another place to look is the formatting rules in the EDD. If some elements have a lot of them, a rule at the bottom of the list may be changing the effect of a rule at the top of the list. The EDD applies the rules in order. If rule 1 sets to the font to 11pt and rule 3 sets the font at 14pt, then the font will be 14pt. Check your rules carefully. Some may not be working as you think they should, or more likely being applied in situations that you did not expect.

Van

[Guest]

Van,

Thanks for your thoughts and advice.

I note that you say you prefer your EDD to govern formatting; me too.   One thing I do find a bit of a headache sometimes is that, particularly when converting XML, I have "para" with about as many context rules as I have other elements, because nearly all the elements in XML allow "para" to be a child.  If it has some special formatting, then it needs a supporting context rule - somewhere.  This can make for a really lengthy "para" element, and, you're right, it's easy to get in a muddle with several different context rules for the same type of thing but with all the same name (para).   Autonumbering, for one thing,  can be a nightmare.

When I do my own EDDs for book writing, for example, I keep it very simple so as to avoid this problem of dependancy, and have my elements describe the formatting in detail - avoids having to bother considering what came before or after.

Regards

Chris

[Van Kurtz]

Chris,

The reason I do the formatting in the EDD is to maintain consistency across the document set. The other way also lets the EDD do the formatting but the EDD assigns paragraph or character tags to elements, instead of the actual formatting. The EDD is still doing the formatting but makes the paragraph and character tags accessible to the writer, which allows the writer to change things, which leads to inconsistency.

Yes, there are certain often-used elements in any EDD that require lots of formatting rules, for example, para and title elements. But to create special elements for each special formatting instance moves away from the idea that XML/structure should be format free. The writer should not have to figure out which title-element goes to which title. This puts the work on the shoulders of the EDD author; however, once completed, the writing process is much easier. So, for this reason alone, I am willing to put the extra effort in making a good, solid EDD.

To beat my chest a little, my EDD has a generic list element, whose attributes determine whether the list is ordered, unordered, or simply indented without decoration. My lists can contain other lists (sublists) and I can intermix lists of different types. Each sublist is indented. If decorated (bullets or numbers), each sublist gets a different decoration, for example, 1,2,3 for the list and a,b,c for the first sublist, etc. It took a long time to get the formatting correct in the EDD, but now I can drag lists in and out of other lists, and the formatting is always correct. I have seen EDDs that have ul, ul2, ul3, ol, ol2, ol3 elements (ul = unordered; ol = ordered; number indicates level). For these EDDs, the EDD work is easier, but the writer has to know when and where to use which list element. Better to make it easy for the writer to get it right, than have to correct them when they get it wrong. Removes a lot of editing work.

Van

[Guest]

Van,

Yup, got all that.

I should've added that my personal EDDs are much smaller.   The XML EDDs are, as you say, much more strict (and longer) in that they have to mirror what's happening on the dark side.   This makes "para" a headache in some cases, especially when doing a long-term EDD development to fit, in our case, the DocBook 4.2 subset.

For instance, I was working through each element in the requirements, testing them out, and moving down the shopping list.   A bizzare thing happened last week:  somewhere between version 6 and 44 of my EDD, in the element for an orderedlist, which has a listitem (which can have several settings - for alphalist itemizedlist, orderedlist and variablelist) the structure for listitem for an orderedizedlist is:

2.  If context is:   orderedlist

     If context is {first}

          Numbering properties

               Autonumber format:  <n=1>.\t\t

     Else

          Numbering properties

               Autonumber format:  <n+>.\t\t

Which used to give what I'd expect:  1, 2, 3, etc, reset for each list 1, 2, 3, etc.

Last week, for some obscure reason, I thought I'd go through all my elements to see if they're working, and somewhere in the morass of formatting that I have under "para" the autonumbering is obviously getting supprerssed, because orderedlist (and for that matter alphalist) now no longer autonumber.

Therein lies the value of testing everything with everything else as you go along.   At the beginning I was doing that, but then started to test things in isolation.   Oh well, back to the drawing board.

Snowing here, so maybe go and build a snowman at lunchtime!

Regards

Chris