Skip navigation
convextech67
Currently Being Moderated

Type mismatch for the element FrameMaker element (graphic)

Jul 11, 2012 7:33 AM

Now that I'm moving along on the formatting portion of this manual (or so I think - ha), I need to start bringing in the graphics to make sure they are all there, so I can get the illustrator going on that end. I've looked at threads everywhere I could find regarding graphic boardno and using the read/write rules to tell FrameMaker what to do with the graphic, and nothing works. I keep getting an error that says, "type mismatch for the element FrameMaker element (graphic). The type defined by the read/write rules is different from thet defined in the template."

 

I created this rw file from scratch out of FM 10. I've copied several different iterations that I've found all over the place. Right now my rw file has this:

 

element "graphic" {

is fm graphic element;

attribute "boardno" {

is fm property entity;

is fm attribute;

}

}

 
Replies
  • Currently Being Moderated
    Jul 11, 2012 8:26 AM   in reply to convextech67

    It is not clear what you are trying to do, but read/write rules are only really necessary when you are reading in or writing out XML. If you are importing files within FrameMaker, FrameMaker does not use or reference your read/write file.

     

    ALSO, note that you should not try to manipulate graphics or import them (within FrameMaker) using the attributes of your graphic element. Within FrameMaker manage your graphics as you would in unstructured Framemaker.

     

    In any event, here is the relevant part from my read/write rules. The dpi drop statement and the write facet statement are there to get XML output with the graphic file dimensions in points rather than dpi; you likely may not need these statements.

     

    element "Graphic" {

        is fm graphic element;

        attribute "file" is fm property file;

        attribute "dpi" drop;

        writer facet default specify size in pt;

    }

     

    Here is my definition of the Graphic element in my EDD. Note that it does not specify the type of the graphic. It simply brings up a dialog to find the graphic file to import.

     

    Element (Graphic): Graphic

    Initial graphic element format

    In all contexts.

    Insert imported graphic file.

     

     

    In structured FrameMaker, graphics (among other objects) have special handling. See the Structured Applications Guide for the details.

     

    Hope this helps,

    Van

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 11, 2012 1:21 PM   in reply to convextech67

    If I were to treat them as an unstructured FM file, that would mean manually importing the graphics by reference, and according to your EDD, that's exactly what you are doing; I am not going to import each of these files manually, otherwise, why am I bothering using Structured FrameMaker with an EDD at all

    In MY case, I create the structured FrameMaker file within FrameMaker, which of course requires importing the graphics by reference; the EDD is simply telling FrameMaker to open the appropriate dialog box when I insert my Graphic element.

     

    THEN I export the fm file to XML, which stores the path name of each referenced graphics file; FrameMaker does this because of my read/write rules. Then when I read the XML file into FrameMaker, the same read/write rules tell FrameMaker where each graphic file is located; FrameMaker inserts the files by reference WITHOUT my intervention. The EDD does nothing during this process; the "Insert graphic file" in the EDD is used only when I first insert the file by reference within FrameMaker, NOT when the XML file is opened by FrameMaker.

     

    By the way, when FrameMaker exports the fm file to XML, it also writes several default attributes to the Graphic element. These attributes describe the sizing and location of the graphic within the anchored frame. They are not specified in the EDD, though I supposed one could. It is for this reason that I mentioned in the original post that one should not manipulate (size, position, and import) graphics by simply assigning values to attributes...when working within FrameMaker.

     

    BUT it appears you are doing something different. You are starting with an XML file that was created outside FrameMaker and all the graphic files are referenced as entities within the XML file itself. Is this correct? If so, I have to admit that I have never worked with entities, but the structured applications guide (for Frame 9) states:

     

    Importing graphic entities

     

    If the graphic element in markup uses the entity attribute to identify the graphic file, then the

    actual graphic file must be identified in an entity declaration. FrameMaker will read the markup,

    importing the graphic file by reference into an anchored frame. If the entity declaration is not in

    the main DTD, then it should be in the document’s internal DTD subset. In that case, FrameMaker

    saves information about the entity declaration on the Entity Declarations reference page of the

    resulting document.

     

    The software saves the entity name with the imported graphic inset. The software uses the entity

    name, plus the information on the Entity Declarations reference page, to recreate entity

    declarations when exporting to markup. For graphic entities the software can use the same

    graphic file for import and export under most circumstances. For information about exporting

    entity declarations, see “Exporting entity declarations” on page 374. For information about when

    the software does and does not use the same graphic file, see “Creating graphic files on export”

    on page 374.

     

    I hope that others more familiar with entities will be able to help you. There ARE some read/write rules for entities; maybe you need them also. You may need an entity attribute in your graphic element, but this is just a guess.

     

    By the way... I create an XML file by a third-party application (parts data), which I then open within FrameMaker, applying an XSLT during the process. The XSLT creates Graphic elements with file attributes that specify the locations of the graphics files. This works well. No entities involved. If you have any control over the creation of the original XML file, maybe you can try an approach that does not make use of entities.

     

    Van

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 13, 2012 6:12 AM   in reply to convextech67

    Still muddling through all the threads I've found to figure out how to make the anchored frames a certain size. The major problem I'm finding is that most of the read/write rules I am finding on the web are all for exporting to XML, not the other way around.

    To my knowledge, the read/write rules used to export to XML are the same as one uses to import the XML back into FrameMaker. This process is called roundtripping. If done correctly, the fm file created when the exported XML is opened in FrameMaker is the same as the original fm file.

     

    Yes, I have valid XML I am pulling into FM simply to print. the file is saved as *.fm as soon as it comes up to deal with any formatting issues so that I can re-import the new formats & any EDD changes into the template.

    You can create a structured application that specifies the location of your new template file. When you open the XML, FrameMaker asks what structured application to use. Pick the one you created. Then FrameMaker opens the XML and applies the formatting AND the EDD that is already there in the template. You do not need to apply new formatting or copy in a new EDD. Note that a template file is simply a blank document with all the formats and the EDD in it. To create a structured application, see the structured application guide for details.

     

    By the way, learning XSLT is not that difficult. Because you are opening the XML simply to print it, your EDD probably parallels the DTD for the XML file. So most of the XSLT is mapping most of the elements into themselves, that is same names and attributes. You just need to add some special templates to manipulate the images into anchored frame sizes that you set within the XSLT. Likewise for the graphics themselves.

     

    I finally figured out that I had my graphic element as a container instead of as a graphic, so now the graphics are appearing, although sometimes they are huge and sometimes they are tiny (not scaled to fit).

    This is due to the fact that the XML is not specifying the sizes of the graphics; so FrameMaker is using the default sizes. If the XML DOES include sizing information in attributes say, then you can either use the XSLT to manipulate them to something that FrameMaker understands or add read/write rules to do it.

     

    Van

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 13, 2012 10:08 AM   in reply to convextech67

    However, whenever new changes have been made to the EDD, the EDD must be imported back into the template, and whenever I've made new formatting changes to the imported document, those formats must be imported into the template as well. FrameMaker does not automatically assume that any changes I have made should be added to the template, and the template and EDD's definitions should match.

    When you open an XML file, the structure application creates a NEW document from the template file, leaving the template file as a blank document. In my opinion, this is what one wants. This keeps the template as a clean starting point. As you know, the formats and the EDD are also in the new document; however, the new document is not connected to the template. Any formatting changes one makes in the new document have to be imported back into the template IF you want those changes to be included with the template.

     

    When you make changes to the EDD, you are making those changes in an EDD document that is separate from the template. Those changes have to be imported back into the template. I do not see how it could be otherwise. For example, you cannot edit the EDD in the new document nor in the template; the EDD is a separate document that can only be edited in that separate document and then imported into the template and any existing document whose EDD you want to update.

     

    And btw, when you keep saying "see the guide or see the reference for details", I don't know about anyone else, but when I resort to asking questions on a forum, it's because I've been through the guide and the references and I need someone's real-world experience. Just saying

    Generally, I state this because I do not want to repeat the details in my post, details that the reader can find in the guides.

     

    On the other hand, I have seen users on this forum who clearly do not read the guides and references. They want someone just to give them step-by-step instructions to do what they want without having to think through the solution or read the guides. As you state, you are not one of those.

     

    Van

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (1)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points