Skip to main content
L
Lynne A. Price
Inspiring
May 10, 2019
Question

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

  • May 10, 2019
  • 1 reply
  • 897 views

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

    This topic has been closed for replies.

    1 reply

    T
    Trevor-Nicholls
    Inspiring
    May 14, 2019

    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

    L
    Lynne A. PriceAuthor
    Inspiring
    May 23, 2019

    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

    T
    Trevor-Nicholls
    Inspiring
    May 23, 2019

    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.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices