Skip to main content
W
Walt Sterdan
Participant
February 18, 2021
Question

Script to find and convert only external x-refs to text

  • February 18, 2021
  • 2 replies
  • 855 views

Before I spend time re-inventing the wheel, are there any scripts around that would convert only the external x-refs in a book to text? The main book file would be the only file with a part number.

 

I imagine it should look something like:

 

Get part number from book file name

  Find Cross-Referece of type "Text"

    if Source Document does not contain "part number" then

       Convert Cross-Reference to text

   end

Next Cross-Reference of type "Text"

 

Is there anything similar kicking around?

 

Thanks,

Walt Sterdan

    This topic has been closed for replies.

    2 replies

    R
    Russ Ward
    Legend
    February 19, 2021

    Hi Walt,

     

    It's not likely that you will find a ready-to-run script laying around, but you might be able to get more advice if you described your need a little more. In particular, I do not understand what you mean by "external xref". It could mean an xref to another file. Or you might mean an xref to another file in another book. Could you clarify?

     

    Russ

    W
    Walt SterdanAuthor
    Participant
    February 22, 2021

    Hi Russ;

    I sweat I posted this on Friday, but this isn't the first time Adobe and I disagree.

    Inside the book folder we have the book file, The main body, the cover file and the TOC, as well as an insets folder.

     

    Outside the book folder is a "Common files" folder where any number of files will reside. The main body file has multiple Xrefs to paragraphs inside the Body file as well as External Xrefs to other files inside the book (e.g. Cover) and a large number to common paragraphs uses throughout any number of books. Currently we open the Body file, list the External Xrefs and select each one linked to one in the Commn files, convert it to text, then select the next one, etc., leaving the External Xrefts that are linked to the Cover or TOC file intact. The "XXX-XXXX" is the part number for the book.

    Typically, manually doing this takes anywhere from 5 minutes to 15 or so. Our client sends anywhere from one to 10 or 15 books every month or two. I'm anticipating some in the next few weeks and I was hoping to cobble together a script that would automate this.

    Thanks,

    Walt

    Book folder
       XXX-XXXX.book
       XXX-XXXXBody
       3XXX-XXXXCover
       XXX-XXXXTOC

    Common files Folder
       COMMON01
       COMMON02
       COMMON0
    R
    Russ Ward
    Legend
    February 23, 2021

    Hi Walt, this does sound like a good use case for scripting. It involves some complexity and I'm not able to just write and test a script for free. But if I could, likely it would be something like this:

     

    1 - A basic search for all xrefs in the doc(s) using doc.FirstXRefInDoc and xref.NextXRefInDoc

    2 - For each xref examine the xref.XRefFile property to see if it contains the common files folder name.

    3 - For a common file xref, store the text location with xref.TextRange and the visible text with xref.XRefSrcText property.

    4 - Delete the xref

    5 - Insert the previously-visible text using the things stored in step 3.

     

    I do ask myself, though... what good is some flattened xref to some place in some external file that is not in the final publication? I can't tell from your description, but it smells like you might be using text insets and the common content is ultimately brought into the published book. If it is, a much better script would be to locate each "external" xref which is actually now less external, find the target in its new location (the place of inset), and re-resolve to that place. Maybe you aren't doing insets. But if you are, that's what I would do rather than just flatten the xrefs. Of course, that is more complicated 🙂

     

    Russ

    Bob_Niland
    Community Expert
    Bob_NilandCommunity Expert
    Community Expert
    February 18, 2021

    I don't do FM scripting, and haven't done any serious MIF-mucking in a while, but in the MIFs, it appears that the difference between a local Xref and an external is clear from the <XRefSrcFile… tag. Using an instance of an external Xref to a file in the same directory:
    local: <XRefSrcFile `'>
    external: <XRefSrcFile `<c\>ExtFileName.fm'>

    That c\… might mean "current", so a ref to a .fm elsewhere in your file system is apt to have dramatically different syntax. The key thing might be processing the instances not empty `'

    W
    Walt SterdanAuthor
    Participant
    February 18, 2021

    Interesting thought, thanks! I hadn't thought of working through the MIFs, it offers a second line of attack.

     

    Much appreciated.

    Bob_Niland
    Community Expert
    Bob_NilandCommunity Expert
    Community Expert
    February 18, 2021

    Walt Sterdan: I hadn't thought of working through the MIFs…

    It's old-school, but works.
    Historically, the annoyance was the need to generate the MIFs, but that can be scripted, and in a thoughtful workflow might well be something you'd want to do on routine save. Once you have the MIFs, any number of tools can chew on them.

    In FM7/Unix, back before FM had an Archive capability, I had written csh/sed scripts to find all the imported objects, copy them to ./images, and rewrite the paths in the MIFs. This was so we could zip it all up and send it out for translation (and we never could be sure of what version of FM the translators had, so MIFs were critical).

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices