Using Framemaker 10, I'm trying to structure a document with a conversion table. I can wrap all character and paragraph tags into an element, but the conversion seems to stop after that first step and subsequent wrapping are not executed. The resulting file have a flat structure with only one level.
I made a sample file with 4 or 5 character tags and the corresponding conversion table, and it still does not work. Here is the samples. I'm expecting elements ArticleTiret, tiret and ArticleTiret to be wrapped in an element SuiviArticle. But as you can see, it does not work
I hope somebody will be able to help me to spot what I'm doing wrong.
Copy link to clipboard
It seems that you have indeed encountered a bug. In particular, when a paragraph begins with multiple text ranges using different character formats, FrameMaker correctly wraps those text ranges in the elements specified in the conversion table. In your case, you obtained the sequence ArticleTiret, tiret, ArticleTiret. However, FrameMaker fails to wrap such sequences in other elements unless the sequence is preceded by another element in the same paragraph or occurs in the first paragraph in the flow.
The problem still exists in FM 2019.
I have filed bug FRMAKER-6696 on this issue.
There is a workaround, but it is cumbersome:
1. Make a backup copy of your document
2, Create a new character format called something like workaround.
3. Type some text such as the word "workaround" and apply this new character format to it.
4. Copy the text to the clipboard.
5. In the Find/Change pod, type \P as the text you want to find (\P is the code for the beginning of a line).
6. Select By Pasting as the way you want to change it.
7. Click change all.
8. Add a row in your conversion table that maps character format workaround to an element of the same name.
9. Structure your document.
10. Go back to Find/Change and Find the element named workaround.
11. In the Change pull-down menu, select Text, but make sure the following text box is empty.
12. Click Change All to change all workaround elements to nothing, thereby deleting them.
Thank you very much Lynne. It worked!
As I process a more complex file, I notice that when Framemaker wraps elements into another (ie ArticleTiret, tiret, ArticleTiret into SuiteArticle), it puts the new element SuiteArticle onto a new line, so it seems that I'm back with the same problem after one iteration: SuiteArticle is at the begining or a line, so it won't wrap. Am I right?
I'm a little baffled by this bug. I structured a couple of documents in the past years with the same version of Framemaker, with the same structure and I never encountered this problem. The only difference I can see is that I was on Windows 7 then and now I'm on Windows 10. But I doubt it could make a difference.
Thanks again for your help.
If you don't already have an EDD, create one and import its element definitions into the structured document created through the conversion table. Does that fix the formatting issue?
Remember that every container can be either one or more paragraphs or a text range within a paragraph; depending on the applicable format rules, some instances of an element type can be paragraphs while others are text ranges. If there is no applicable format rule, FrameMaker makes a container a separate paragraph.
Before structuring the unstructured document, if you have an EDD, import element definitions into the unstructured document. FrameMaker will retain and apply those element definitions in the new structured document. If it creates a structured document with a conversion table and the unstructured original does not have element definitions, FrameMaker creates some. It gives every container the general rule <ANY>. When a character format or element format is mapped to an element, it gives that an element a single text format rule that assigns it the first character or paragraph format assigned to that element in the conversion table. For example, if paragraph formats Numbered and Numbered1 are both mapped to the element Item, the definition of Item will assign whichever of those paragraph formats was used first.
It does not create format rules for containers built from sequences of other elements. In your case, SuiviArticle will not have a format rule, so it will be interpreted as a separate paragraph. My guess is that the line break you are seeing is not a data character; it is the result of structure-based formatting.
You can extract the element definitions that FrameMaker creates with Structure > EDD > Export Element Catalog as EDD.