Trouble with character format and element definition brackets

[Banzwanaman]

I am converting unstructured documents to structured documents. I have a "Paragraph" element, which allows "ParagraphTitle" elements, <TEXT>, and other "Paragraph" elements under it (simplifying for ease of explaining the issue).

The "ParagraphTitle" element has the following EDD:

Element (Container): ParagraphTitle

     General rule: <TEXT>

     Text format rules

          In all contexts.

               Text range.

               Font properties

                    Underline: Single

The "ParagraphTitle" element comes at the beginning of the "Paragraph" element. The problem is that after the conversion the underline character formatting is bleeding into the parent element's element definition brackets, as shown below:

(you can see the underline at the brackets).

What this does, is it causes a tiny underline at the end of the "Paragraph" element in the printed PDF:

This is driving me crazy, because I have to cleanse the formatting and reapply the character formatting for the entire element (which, for a high level paragraph, can also mean reformatting a large number of child elements). It is causing a lot of unnecessary rework, wasting a lot of time. Any help would be appreciated.

[Russ Ward · Accepted solution]

Hi Banzwanaman,

You probably have to live with it. I have used structured FM for a long time and there have always been quirks and anomalies with element bracket formatting.

But, your request raises an obvious question... why are you keeping the brackets in the published output? I think that their purpose is for authoring convenience only. In fact, FM used to give you a warning before making a PDF with the brackets showing... not sure if it still does. Anyway, if there are oddities with bracket formatting, I suspect it would be a low priority for Adobe engineering, as this is not an expected use case.

Russ

[Banzwanaman]

Thanks for the input, Russ. I've changed my process to apply the element tag to the text after I convert the document. It just seems silly that these little blips show up.

To answer your question, I don't publish the document with the brackets showing. It's just that the underline still shows up in the final PDF, even though the element brackets aren't showing. It's a little problem, but it seems like it shouldn't be.

[Russ Ward]

OK, I did not realize that you were seeing the problem with brackets hidden. My apologies. In this case, it is reasonable that you should *not* have to live with it. I would consider a bug report.

Does it go away if you reimport element definitions? I find that I have to reimport definitions frequently to keep the formatting clean. I do it so much that many years ago I built it into a plugin with a keyboard shortcut:

WS Structure Tools - West Street Consulting

I use that shortcut on a regular basis every day. I don't know how anyone can live without it, and I don't say that to promote my software. The plugin is not free but you can install the trial version which is fully functional and that particular shortcut will always work without bothering you for payment. And, you can make the shortcut whatever you want.

Russ

[Trevor-Nicholls]

I'm seeing something similar. Our schema allows for included subfiles which, while editing, are formatted by our EDD so that a prefix and suffix demarcate the inclusion. Something like this:

Element (Container😞 included

General rule: document | section | content

Attribute list

   1. Name: srcfile     String     Required

Prefix rules

1. In all contexts.

   Prefix: Included:

   Text range.

   Font properties

     Color: red

Suffix rules

1. In all contexts.

   Suffix: End Included

   Text range.

   Font properties

     Color: red

When included content is displayed, the prefix is correct but the suffix has a trailing >, thus we see

Included:

  some content

End included>

It gets worse: if I try to add the source filename to the prefix and suffix, like this:

Prefix rules

1. In all contexts.

   Prefix: Included: <$attribute[srcfile]>

Suffix rules

1. In all contexts.

   Suffix: End Included: <$attribute[srcfile]>

then the prefix is correctly constructed, including the value of srcfile, but the suffix is just reproduced as though it were a literal:

Included: mydoc_sub.xml

  some content

End included: <$attribute[srcfile]>

It's interesting that in this scenario the trailing > does not appear.