Copy link to clipboard
Copied
We are starting to include an amount of text insets for FM files.
In this starting period there are changings that happen.
If the name or the path of a text insets change, you have to repeat the
import procedure for every single text inset.
For changes of referenced graphics (path or name) FM has a fine working procedure:
When loading a FM file a message comes up with the uncorrect graphic file. You have
to change the reference and the correction is done.
If you changed the name of the graphic directory you have to change the new name for the
first graphic file and all references will change afterwards automatically.
Both procedures does not work for text insets. My questions:
I'm working with FM 10: Does anybody knows if there is a work-around for me?
Does anybody knows if there are features for processing text insets in FM 12?
Thanks in advance
A-Bel,
I'm glad to hear that you decided to take the plunge! I didn't know what experience you already had, so I didn't try to go any further. With specific questions, though, I'm happy to assist further.
For literals in Javascript and most other languages (that is, a string within quotes), a backslash is a special character. So, to end up with a single backslash, you have to put two. It's called an "escape sequence." Anyway, based on your input, I would think that the following would be appropria
...Copy link to clipboard
Copied
Unfortunately, text insets don't allow path updates as graphics do, and this behaviour hasn't changed with FM12 either.
The easiest way to make large-scale changes to insets is to edit the MIF version of the files and look for the <TiSrcFile pathname> statement. Change the "pathname" component to reflect the new location. The syntax for the pathname is: `<v\>c:<c\>mydir<c\>subdir<c\>filename' on Windows (see the MIF Reference manual).
Copy link to clipboard
Copied
The update-path behavior evidently only works for ImportObFile objects and not TiSrcFile objects.
As Arnis indicates, you can write a script to process MIFs, and re-factor the paths. I've done it, and it's a bit of a nuisance (depending on the tools used) because the import expressions and paths are loaded with special characters that must be escaped. The coding effort is usually only worth it for more than 100 instances, or for things you need to do periodically.
For a smaller number of cases, if the old file path still exists (and only the files do not), just create a text string representing the new relative file path from the old directory to the new, and paste it in ahead of the filename as you re-import each inset. Paste & click for each.
Copy link to clipboard
Copied
This is exactly the kind of thing that ExtendScript is made for. I'd say that ES is by far the easiest way, if you know how to use it. This example is but one of many case studies for why scripting knowledge is a big advantage to an FM user.
The following script will go through a whole document and do a search/replace within text inset paths, according the the search and replace strings specified. It is a short, simple script with around 20 lines, and took a short time to write. Compare that with manually changing each inset. It is a perfect example of how a little bit of knowledge can have a huge benefit, both for you the user and the longevity of the FM platform. I encourage anyone to learn more. But before I get out of control, let me just leave it at that and hope that this might be helpful.
Russ
updateTextInsetPaths();
function updateTextInsetPaths()
{
var searchString = "some\\path\\string\\to\\change";
var replaceString = "the\\new\\path\\string";
var doc = app.ActiveDoc;
if(!doc.ObjectValid())
{
alert("No active document. Cannot continue");
return;
}
var pathsUpdated = 0;
var inset = doc.FirstTiInDoc;
while(inset.ObjectValid())
{
var path = inset.TiFile;
path = path.replace(searchString, replaceString);
inset.TiFile = path;
pathsUpdated++;
inset = inset.NextTiInDoc;
}
alert("Operation complete. " + pathsUpdated + "path(s) updated.");
}
Copy link to clipboard
Copied
Thank you all for your suggestions! That helps a lot!
What a lucky day!
I did not test the MIF thing because I`d like to be successful with this ExtendScript.
Fortune is fickle!
I don´t have any idea how to define the searchString and the replaceString:
var searchString = "some\\path\\string\\to\\change";
var replaceString = "the\\new\\path\\string";
Sorry for posting these silly questions. I am not able to customize the script to my circumstances:
The fm files are in C:\Users\annette\documentation\manual\fm
The text insets were in C:\Users\annette\documentation\modules (=searchString)
The text insets are now in C:\Users\annette\documentation\manual\ti (=searchString)
I tried various absolute and relative paths using / or \, but without success.
The scripts gives me the successful message "Operation complete. 41 path(s) updated."
But the TIs still have false references.
Copy link to clipboard
Copied
a slip of the pen - this is correct:
The text insets are now in C:\Users\annette\documentation\manual\ti (=replaceString)
Copy link to clipboard
Copied
A-Bel,
I'm glad to hear that you decided to take the plunge! I didn't know what experience you already had, so I didn't try to go any further. With specific questions, though, I'm happy to assist further.
For literals in Javascript and most other languages (that is, a string within quotes), a backslash is a special character. So, to end up with a single backslash, you have to put two. It's called an "escape sequence." Anyway, based on your input, I would think that the following would be appropriate:
var searchString = "documentation\\modules";
var replaceString = "documentation\\manual\\ti";
Congratulations on figuring out how to open the ESTK toolkit and run the script. By the way, the script is just reporting how many paths it adjusted... it isn't advanced enough to actually determine if they were adjusted to be valid paths. This would be a relatively simple addition to the script but I didn't want to complicate things further. If you are interested though, I could work up a more advanced sample that actually checks if the target files exist while changing paths. That would be kind of neat, I think. Let's see if you can get it to work in its current version first, though.
I should have also added the warning to make backups before running the scripts, or at the very least, don't save anything until you know it's right. You seem savvy enough to know better, though.
Russ