Why does FM create files called img1.mif, img2.mif, etc. when saving an XML document

[Lynne A. Price]

Trevor-Nicholls started a discussion last month on creating an XML document from the welcome screen (Re: Creating a new document from the Welcome screen, doesn't ). That discussion has grown to include several related topics, so I am splitting my responses in new discussions specific to individual subtopics. This is the second such new discussion.

One of his comments included "... in this configuration Frame seems to be creating img1.mif, img2.mif files which it wasn't before. Where might they be coming from?"

I suspect they are coming from anchored frames in the saved document. FM represents a graphic in XML with a reference to a file containing the graphic. The reference can either be a filename or the name of an external data entity that itself names the graphic entity. If the anchored frame contains a single imported image, the XML representation identifies the imported file. If the anchored frame consists solely of objects drawn with the FM drawing tools, multiple imported images, an imported image and callouts, then there is no existing file to be referenced in XML. FM therefore creates one. Read/write rules can specify the graphic format to use as well as the prefix that precedes a sequence number in the file.

     --Lynne

[Trevor-Nicholls]

Hi Lynne

I think I have to put this one down as a user error. I was able to reproduce it by inserting an image wrapper element in a new document, then closing the import graphic dialog without picking an image. I'm sure in earlier versions this left the wrapper element without an image child, which would fail "structure > validate" and/or give an invalid document error on save. It's now creating the image child and pointing it at img1.mif, etc. Something else to check on in the post-process.

cheers

T

[Lynne A. Price]

Trevor,

   It sounds like you have created an empty anchored frame; since there is no existing graphic file to export to XML, FM creates such a file. I do not believe FM's behavior in this area has changed with different versions. You mention a wrapper element and an image child. Is the wrapper a container and the image a graphic? Does the structure defined in the EDD match that you use in XML? What actions do you take to create the erroneous results?

         --Lynne

[Trevor-Nicholls]

Hi

The <wrapper><img /></wrapper> unit is required because images in our XML schema potentially have a few attributes that don't map directly to FrameMaker's graphic element. So our pre-processor stylesheet converts <img lots-of-attributes/> into <wrapper some-attributes><img relevant-attributes-for-Frame/></wrapper> and then the conversion  into Frame picks up the image dimensions and alignment etc via read-write rules. When saving the document the reverse happens: img and wrapper attributes are merged into the single image element.

In the EDD a <wrapper> is a container and an img is a graphic.

[Trevor-Nicholls]

I discovered that one of our users had committed changes to a document that caused our application to report missing images: the aforementioned .MIF files. We'd been using FM8 off and on for about 10 years and I'd never seen this happen before.

When a user is editing a document they cannot insert an image directly; the content model only allows it within a wrapper. The EDD automatically inserts an img with a wrapper, and the user is prompted to select an image in a file dialog. If they cancel out of this the document won't validate. If they select an image and later delete the img element from the structure view the document won't validate. What I think they must have done is select the graphic content within the frame in the document view and pressed the delete key. This does not delete the wrapper element and it does not delete the img element either (maybe it should?). What it does do is remove the file reference from the graphic object, but leaves the object there; the document validates and can be saved, and Frame creates the .MIF file locally. The user is oblivious to this so the .MIF file never gets committed to our repository. I've just reproduced this.

It's not a Frame error, but it's behaviour which I need to document for our users so they are aware of it.

cheers

T