Copy link to clipboard
Copied
Hi all,
I'm having some difficulty getting my EDD to properly format based on XML attributes. Basically what I'd like is this:
I have some XML:
<root>
<elem>Sample text sample text sample text sample text.</elem>
<elem multi="true">Sample text sample text sample text sample text.</elem>
</root>
For elements with the multi="true" attribute, I'd like them to be prefixed by a bullet and with a left indent of 0.14" so that the text aligns with the bullet.
• Sample text sample text
sample text sample text.
Those without the attribute are simply formatted according to the specified paragraph format (no prefix, left indent 0.0")
Sample text sample text
sample text sample text.
My EDD looks like this:
Element (Container): elem
General rule: <ANY>
Attribute list
Name: multi String Optional
Prefix rules
If context is: [multi = “true”]
Prefix: •
Text format rules
Element paragraph format: Element
If context is: [multi = “true”]
Basic properties
Indents
Left indent: 0.14”
After importing my XML, the prefix part works perfectly. No problems there.
However, the context-based left indent doesn't work at all -- all elements just inherit the paragraph indent (0.0"). So it ends up looking like this:
• Sample text sample text
sample text sample text.
I can't seem to figure this out. Does formatting in the EDD not override the specified paragraph formats or something?
Any help would be greatly appreciated.
Thanks,
Carl
1 Correct answer
Please disregard the incomplete response I seem to have posted. What I was starting to say is:
Carl,
An element's format rules override formatting it inherits from its parent, so the rules for parentElement should not interfere with those you specify for elem.
I don't see the problem, and without actually opening the file in FM, it's difficult for me to guess what might be wrong. A couple of things I would do are:
1) Set another property in the rule for <elem>, for example, set the font size t
...Copy link to clipboard
Copied
Carl,
Your example includes:
<elem multi="true">Sample text sample text sample text sample text.</elem>
By any chance does the actual document have a subelement within the <elem>? If so, is the formatting of the subelement overriding the formatting of the <elem>? You can use the StructureTools > Show Element Context command to confirm that the formatting rules you have intended are firing.
Also, when you are debugging your EDD, I recommend checking the box to remove overrides each time you import element definitions.
--Lynne
Copy link to clipboard
Copied
Hi Lynne,
<elem> does not have any child elements, but it is a child element of another element. The parent element has the following EDD rules:
Element (Container): parentElement
General rule: elem
Attribute list
Name: multi String Optional
Text format rules
Element paragraph format: parentElement
Prefix rules
If context is: [multi = “true”]
Prefix: Notes: \n
Else
Prefix: Note:
Is it possible that the parent element is stopping the child element from receiving formatting? When I look at the element context, it shows (for the parent element):
Prefix Rules
->Rule #1 (context rule)
->if [multi = "true"]
Prefix string: Notes \n
No additional formatting
Else
Prefix string: Note:
No additional formatting
And for the child element, it looks like everything should be working properly...
Text Format Rules
->Rule #1 (context rule)
->if [multi = "true"]
Apply format change list
Copy link to clipboard
Copied
Carl,
An element's format rules override formatting it inherits from its parent, so the rules for parentElement should not interfere with those you specify for elem.
I don't see the problem, and without actually opening the file in FM, it's difficult for me to guess what might be wrong. A couple of things I would do iare:
1)
Copy link to clipboard
Copied
Please disregard the incomplete response I seem to have posted. What I was starting to say is:
Carl,
An element's format rules override formatting it inherits from its parent, so the rules for parentElement should not interfere with those you specify for elem.
I don't see the problem, and without actually opening the file in FM, it's difficult for me to guess what might be wrong. A couple of things I would do are:
1) Set another property in the rule for <elem>, for example, set the font size to 70pt as well as changing the left indent. A change in the font size will confirm that the rule has actually fired.
2) Inspect the left indent in the paragraph designer. Might you have set it to 0.14pt instead of 0.14in?
--Lynne
Copy link to clipboard
Copied
Thank you Lynne! It turns out FM EDD's don't like 0.14", but as soon as I changed it to "0.14 in" it worked perfectly. It's always the little things that get ya...
Copy link to clipboard
Copied
Carl,
Hmmm. What version of FM are you using? I did some testing with FM 2015. I created a one-element EDD in which there was a single AllContextsRule in which I tried setting the left indent to various tests to variations of "0.14in". Omitting the leading 0 made no difference. Neither did changing the "in" abbreviation to a quotation mark (I tried single and double quotes as well as straight and curly quotation marks). I also tried with and without a space between the ".14" and the units and omitting the units. After the single quote produced the same result as a double quote, I tried an asterisk and then the letter 'x'. The result did not change until I used a different FM units abbreviation ("pt" instead of "in").
--Lynne
Copy link to clipboard
Copied
The results of your testing indicate that FrameMaker is defaulting to using inches.
The default units might be hard-wired, but might instead be derived from the units (View > Options, Display Units and/or Font Units) for either the template or the EDD. I'm afraid that I don't have any structured application available right now to test this myself.
Copy link to clipboard
Copied
Mike,
Changing the Display Units did not make a difference. I was surprised that it was the default, because my aging memory is sure it was something else in earlier versions of FM. However, I did not take the time to do more testing.
--Lynne

