7 Replies Latest reply: Jul 13, 2012 10:08 AM by Reviewer1066 RSS

    Type mismatch for the element FrameMaker element (graphic)

    convextech67

      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;

      }

      }

        • 1. Re: Type mismatch for the element FrameMaker element (graphic)
          Reviewer1066 Community Member

          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

          • 2. Re: Type mismatch for the element FrameMaker element (graphic)
            convextech67 Community Member

            From what I understand from the Structured FM Guides that I have read, which, by the way, contradict each other in the examples they give, I have to have an EDD to open the valid XML in FrameMaker. In order to get FM to display the graphic (they aren't displaying without the rw file), I was told I have to specify a rw rule to tell FM to display the boardno (the reference to the entity) as an entityref. I tried that, amongst other things, and so far I have been unable to get my graphics to display.

             

            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? I would just use the old unstructured FrameMaker files this manual was originally built in and go from there. But we want our data in XML so that it can be further converted into an IETM.

             

            At any rate, thanks for the reply.

            • 3. Re: Type mismatch for the element FrameMaker element (graphic)
              Reviewer1066 Community Member

              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

              • 4. Re: Type mismatch for the element FrameMaker element (graphic)
                convextech67 Community Member

                Thanks again

                 

                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.

                 

                I do have control over how this process works, but I am trying to do this as much within FM as I can simply because I am not that experienced with XSLT, and because I am on a government computer and they do not allow me to install plug-ins or FrameScript. Otherwise I would already have this done! LOL (I think.)

                 

                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).

                 

                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.

                • 5. Re: Type mismatch for the element FrameMaker element (graphic)
                  Reviewer1066 Community Member

                  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

                  • 6. Re: Type mismatch for the element FrameMaker element (graphic)
                    convextech67 Community Member

                    I have the application already set up; I did that first. 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.

                     

                    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

                     

                    Have a great weekend!

                    • 7. Re: Type mismatch for the element FrameMaker element (graphic)
                      Reviewer1066 Community Member

                      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