FDK: Tables and text runaround

Report · Jan 07, 2010

Hi there

I have an FDK client which is used to translate FrameMaker documents, amongst other things. The basic process involves reading in the FrameMaker file, recording the text and any objects and their properties in special tags. After this, the document is wiped clean and reconstructed, with the new translated text in place of the original.

I'm having a very peculiar problem whereby if a paragraph is followed by a table or an anchored frame, when we delete and replace the paragraph text using the FAPI, the text runs around and below the frame/table, so the table or frame ends up below the first line of the paragraph, not the last.

Our customers have flagged this as a very important issue as they are working with documents dozens or hundreds of pages long, and thus may contain many instances of the objects I just mentioned. This issue therefore substantially increases the amount of post-translation desktop processing that needs to be done.

I'm wondering if this is a known issue or something that has a workaround. Any comments or suggestions would be greatly appreciated,

Thanks

Eric

Report · Jan 07, 2010

Eric,

A table always appears below its anchor. To avoid any ambiguities about where to place the table anchor, many document templates use a special paragraph format (like e.g. "TA Table Anchor") to exclusively hold that anchor. I have seen this format using bold red text formatting which only becomes visible if someone erroneously enters text in such a paragraph.

From your description I assume that during the "reconstruction" the table anchors are not inserted at the end of the original paragraph but the beginning. I assume this can be fixed in your FDK client.

- Michael Müller-Hillebrand

Report · Jan 07, 2010

Hi Michael

Thanks for your reply. On looking back at my original post, I was unclear in stating one point - when I say wiped clean, I mean we erase FTI_String and FTI_HardLineEnd text items. We dont actually delete anchors or tables. What we were doing before was attempting to reposition the anchors after translation to their pre-translation locations, but this produced strange behaviour such as tables being duplicated a number of times in succession, so I removed the repositioning logic, and it solved that issue, but subsequently created this one.

It just seems that anchors and tables are not flowing with the newly created text, rather staying where they are and forcing the text around them. Are there any paragraph runaround properties that need to be taken into account when creating new paragraphs?

Eric

Report · Jan 07, 2010

Eric,

If you delete the String data, the marker is repositioned and if you later add String data to the end of a paragraph you add it after the remaining table anchor. I guess you have to start adding text at offset 0 (the beginning of the paragraph in unstructured paragraphs without auto-numbering) and keep track of your offset inside the paragraph while adding your translated data.

Or, after finishing each paragraph, check it for table anchors and cut and paste them to the end of the paragraph.

Tables have no run-around settings.

All of this is usually handled by Translation Memory tools (Trados, Transit) quite nicely, so what you see is essentially the result of your non-standard way of handling translations.

Good luck,

- Michael

Am 07.01.2010 um 16:59 schrieb eric247:

Hi Michael

Thanks for your reply. On looking back at my original post, I was unclear in stating one point - when I say wiped clean, I mean we erase FTI_String and FTI_HardLineEnd text items. We dont actually delete anchors or tables. What we were doing before was attempting to reposition the anchors after translation to their pre-translation locations, but this produced strange behaviour such as tables being duplicated a number of times in succession, so I removed the repositioning logic, and it solved that issue, but subsequently created this one.

It just seems that anchors and tables are not flowing with the newly created text, rather staying where they are and forcing the text around them. Are there any paragraph runaround properties that need to be taken into account when creating new paragraphs?

Eric

--