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

[Walt Sterdan]

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

[Bob_Niland]

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 `'

[Walt Sterdan]

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

Much appreciated.

[Bob_Niland]

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).

[Russ Ward]

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

[Walt Sterdan]

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

[Russ Ward]

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

[Walt Sterdan]

Thanks for the code hint, and good queston.

It's true, flatteninng the X-refs inside the Common files wouldn't make a whole lot of sense. What we're doing, though, is finding the external X-refs inside the book files and flattening the text there, inside the book, not in the Common files, making each book package independant of the external Common files. While the Common files method works very well for our clients all working off a single server, due to the nature or our work and our contrators, it's not possible and having multiple copies of the Common files floating around cause more problems thatn simply having the relevent text translated in each book project. Once the external X-refs are flattened, each book folder (with it's insets folder) is a complete, independant package.