Forcing relative pathnames for linked images

[4everJang]

According to the help files, FM automatically uses relative pathnames for images if they are below the level of the FM file. So why am I having problems when translated files are returned to me to be finalized and printed ?

My linked images are in subfolders of an "images" folder that is next to the FM files. As long as I do not save the FM file somewhere else, the images are found. When I receive translated FM files (I do not send the image files along with the source files), very often all image references are lost and FM is looking in different folders using non-existent pathnames. I think this is a serious design flaw in FM, as I also believe that only using one single directory to search for images is something that should have been abandoned somewhere in the 17th century.

I would be very, very pleased if there would be an easy way of telling FM once and only once for the whole book that the root of the images folder has changed.

Hopefully someone on this forum has an easy solution for this that does not involve trying to change the way the translation agencies export, import and convert my FM files to create their final deliveries. I do not have access to their strategies and it must be possible to do this easier from within FM.

Thanks a bundle for useful suggestions.

Jang F.M. Graat - Amsterdam
(yes, those are my real middle names - I guess my parents knew I was going to work with this product a lot...)

[Art Campbell]

Your translators aren't preserving the path and directory structure and are substituting different locations.

To fix this, use Bruce Foster's Archive plugin to package the files to send to the translators, and tell them not to change these locations.
Or if you want to do it yourself, package your entire project for the translators (an archive that preserves paths) and tell them not to change the image directory location.

If you do neither of these things, when the translators open the files and don't find the graphics, all they have to do is select the option to "Ignore Missing Files" and work without graphics. The pathing is preserved and should work when you receive the files back.

Art

[4everJang]

Thanks Art,

but this does involve changing the way the translation agencies work. Translators do not get the FM files to work on, but some kind of files exported from the MIF files. I am afraid the changes to the image directories happen at some stage along their (automated) ways to create the input for the translators and then import the output from the translators to create a set of MIF files again.

Also, sending the entire set of files (including graphics) in an archive, preserving the paths, is not an option as the graphics easily reach 100 MB or more and this makes it virtually impossible to transfer the files via e-mail. I am only sending an archive of the FM files, with a low-res PDF that includes the images, for reference.

With some agencies this process works flawless, but the cheaper the agency, the lower the quality I guess. Unfortunately, my customers go for cheap rather than quality, and I have the job of fixing the problems in the layout.

Thanks for the suggestion, anyway.

Ciao again from Amsterdam

[Art Campbell]

Jang,

In my experience, the customer pays for translation one way or another... The translation outfits I've dealt with support Frame files. So the customer can either pay for a good translation in the native environment or pay you to clean them up.

As far as sending the graphics along, if you train your translators to select the Ignore Missing Files option when they open the files, your existing paths will be preserved. (As far as file transfer size goes, most translation outfits have FTP sites for file transfers, or you can use any of half-a-dozen "large file" transfer outfits to do the work on both your and the recipient's sides.)

That side track aside, because nothing can really be exported directly from the MIF files, someone, somewhere, is opening them in Frame. They may then be exporting to Word, text, or something else, but someone in your translation chain is using Frame. The problem is likely occurring because whoever is doing the work isn't round-tripping the files properly, so some information may be corrupted.

In any case, if you're getting MIF or Frame files back in, you can edit them in MIF at that point to correct the paths.

Art

[4everJang]

Hello again Art,

I am currently investigating creating a FrameScript that will correct the paths - this has the added advantage that the script can tell me which images are missing, in a list instead of the very limited "Missing File" dialog (which does not even resize to see the full path and thereby creates some confusion sometimes). Also, when Frame finds a file by me pointing to the correct path it assumes that all further files will be in the same place. And since I have files with the same names (but different contents - as they are used in different machine modules), this causes unexpected errors.

And of course you are right in your comment about the translation agency: the previous one that I used responded to my problem reports by changing their methods of exporting and importing. But they are too expensive for the taste of my customers. Ah well, I am getting more out of it this way and my customer knows that, but I hate stupid work even if I do get paid for it.

Ciao again

Jang

[_Van_Kurtz_]

Jang,

I just want to correct a statement in your original post. You said that

According to the help files, FM automatically uses relative pathnames for images if they are below the level of the FM file.

This is not true; the image files do not have to be at a level lower than the FM file. They just have to be on the same volume as the FM file. If on the same volume, the FM file can be below the image files in the hierarchy.

I would also like to emphasize one of Art's points---train your translators to ignore missing images. They should be trying to work WITH you rather than AGAINST you, even if they are cheap.

Good luck,
Van