FM 10 sometimes changes graphics paths

[Heiko Haida]

Hi Harro, 

this is a bug and I think it has been discussed here already. 

The link information will be truncated in the mif (not in the FM file
itself) to the max possilble no. of folders available in the folder
hierarchy at the level where the mif file is actually stored to (not
where the FM file is stored) ! 

In your case, you need 2 more hierarchical folder levels. 

Hi Winfried, 

yes, FrameMaker searches for missing graphics in the last successfully
opened graphics folder (of the actual session at least). So, if you have
just opened a first file, all missing graphics for the second file will
be replaced with graphics for the first file if they have the same
names, without checking if they are identical. 

This can be very annoying and therefore I recommend to use unique IDs
for graphics (including version/revision) instead of or in addition to
simple names. 

Best regards - Tino H. Haida, Berlin 

Reng, Dr. Winfried: 

> Hi, 
> 
> I think this is a bug! 
> 
> Steps: 
> 
> Copy a file with a referenced graphics into another folder. The graphics path might be .graphicstest.eps 
> 
> Open the first file. 
> 
> Then open the copied file. It will show the referenced graphics although it should complaint that the graphics file could not be found in .graphics. 
> 
> Obviously FrameMaker calculates for the copied file the graphics path to the graphics file the first file. 
> 
> Best regards 
> 
> Winfried 
> 
> FROM: Syed Zaeem Hosain (Syed.Hosain at aeris.net) [mailto:Syed.Hosain at aeris.net] 
> SENT: Wednesday, January 14, 2015 7:57 PM
> TO: Reng, Dr. Winfried; framers at lists.frameusers.com
> SUBJECT: RE: FM 10 sometimes changes graphics paths 
> 
> Winfried Reng said: 
> 
>> However, I do not know how FrameMaker gets the path 
> 
>> to the orginal graphics files. 
> 
>> Does this happen only, if another file is open which points to 
> 
>> the graphics files of the copied file? 
> 
>> Otherwise I wonder how FrameMaker can find out where the 
> 
>> graphics files are located. 
> 
> That part of detecting the absolute file location is easy. After a program accessing a file (through all the relative references), determining the absolute location of a file is trivial in code. 
> 
> The truncation mentioned by Harro is troublesome though. 
> 
> Also, there is a path length limit in Windows - I thought it was 256 characters, but may be 64 characters? And this does not explain the network file name issue mentioned … 
> 
> I'll look … 
> 
> Z 
> 
> FROM: framers-bounces at lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] ON BEHALF OF Harro de Jong
> SENT: Wednesday, January 14, 2015 10:35 AM
> TO: framers at lists.frameusers.com
> SUBJECT: FM 10 sometimes changes graphics paths 
> 
> hi all, 
> 
> I recently ran into an issue: we received a set of FrameMaker files for translation. After we sent the translated files back to the customer, they complained that all of the image paths in their files were changed. 
> 
> They were using relative paths that had lots of 'parent' references: 
> 
> ............Graphicsetc 
> 
> When I received these files, I placed them in a directory 4 levels deep: 
> 
> F:Customerprojecttranslationincomingblah.fm 
> 
> When I opened this file Frame asked for the location of external graphics. I selected 'Ignore all missing files' and saved the file as MIF. 
> 
> When I inspected the MIF, the graphics paths were truncated to 
> 
> ........Graphicsetc 
> 
> So the path gets truncated to the number of levels available from the current location. 
> 
> When I store the file on an UNC path, it gets worse: 
> 
> \ServerCustomerprojecttranslationincomingblah.fm [1] 
> 
> graphics paths: 
> 
> \Graphicsetc [2] 
> 
> In my opinion, this is a bug. When I select 'Ignore all missing files', Frame should leave the existing paths alone. 
> 
> Has anyone else seen the same behavior? 
> 
> Harro de Jong
 

Links:
------
[1] file:///\ServerCustomerprojecttranslationincomingblah.fm
[2] file:///\Graphicsetc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20150115/6b760371/attachment.htm>