Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

EDD context-formatting based on XML attributes

Community Beginner ,
Nov 16, 2015 Nov 16, 2015

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

TOPICS
Structured
1.4K
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Advisor , Nov 16, 2015 Nov 16, 2015

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

...
Translate
Advisor ,
Nov 16, 2015 Nov 16, 2015

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

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 16, 2015 Nov 16, 2015

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

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Nov 16, 2015 Nov 16, 2015

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)

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Nov 16, 2015 Nov 16, 2015

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

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 16, 2015 Nov 16, 2015

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...

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Nov 16, 2015 Nov 16, 2015

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

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Contributor ,
Nov 17, 2015 Nov 17, 2015

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.

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Nov 17, 2015 Nov 17, 2015
LATEST

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

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines