Skip to main content
Known Participant
September 17, 2009
Answered

FDK: Problem roundtripping cross-references

  • September 17, 2009
  • 2 replies
  • 894 views

Hi there

I have an FAPI client which translates all the text in a FrameMaker document to another language.

The process involves parsing the Frame document, translating the text, deleting the text originally

in the file and writing the translations back to the document.

One of the documents I've been testing with contains a variable, which, in turn, contains a cross-reference.

However, I'm finding that after we translate the text that the cross reference points to, the variable text

no longer appears in the document. Additionally, the source text for the cross reference in Special->Cross Reference

is blank. I'm wondering why this might be.

I've saved the pre- and post-translation documents to .MIF to inspect the structure of the document. The paragraph

pointed to by the crossref is still in the doc, still retains its paragraph tag, its unique ID and its "referenced" status. So it's a

bit of a mystery to me.

Any suggestions would be most helpful

Thanks

Eric

    This topic has been closed for replies.
    Correct answer Art_Campbell1

    You mention that "... The paragraph pointed to by the crossref is still in the doc, still retains its paragraph tag, its unique ID and its "referenced" status," but you don't actually mention that the cross-reference marker itself survives.

    If you look at the text with View > Optioons > Text Symbols activated, you should see a bold T in the tag, usually at the very beginning of the line. You can verify that this is the Cross-Ref Marker by opening Special > Marker and highlighting the T to see that the marker type is indeed a Cross-Ref marker -- the content field should be empty.

    Art

    2 replies

    Arnis Gubins
    Inspiring
    September 17, 2009

    Eric,

    You also have to have the XRefSrcText component match in both the target and source locations. By default, FM uses the paragraph text along with an id number to build this string. So, if you've subsituted text strings, make sure that they match everywhere. Check with the MIF manual on cross-references for the info on what FM writes in the cross-ref and and at the insertion point.

    eric247Author
    Known Participant
    September 17, 2009

    Hi Guys

    Thanks for your responses - I've discovered that the source string

    for the segment starts with a carriage return, and is confusing

    our software, causing it to add spurious CR's to the string on the way out.

    This is pushing the text into a paragraph with a different tag to the one

    the cross reference is set to use, breaking the xref.

    Sorry for taking up your time, but your answers are actually very useful to know

    anyway, and I'll give all of you "helpful answer" credits

    Thanks

    Eric

    Art_Campbell1Correct answer
    Inspiring
    September 17, 2009

    You mention that "... The paragraph pointed to by the crossref is still in the doc, still retains its paragraph tag, its unique ID and its "referenced" status," but you don't actually mention that the cross-reference marker itself survives.

    If you look at the text with View > Optioons > Text Symbols activated, you should see a bold T in the tag, usually at the very beginning of the line. You can verify that this is the Cross-Ref Marker by opening Special > Marker and highlighting the T to see that the marker type is indeed a Cross-Ref marker -- the content field should be empty.

    Art

    Legend
    September 17, 2009

    Hi Eric,

    I think Art is right. For a little more explanation, cross-references of this type link to a marker in the text, not to the unique ID of the paragraph. The marker is created automatically when the cross-reference is created. More than likely, your text replacement process is inadvertantly deleting these markers.

    When you retrieve the textItems in your code, those markers will also be in that structure. You might have to put in provisions for them, similar to how you are handling tables. I would think, though, that the FTI_String fragments would break at the marker, so I don't know right off why your text replacer is deleting the markers.

    Russ