Skip to main content
convextech67
convextech67
Known Participant
July 11, 2012
Question

Type mismatch for the element FrameMaker element (graphic)

  • July 11, 2012
  • 1 reply
  • 2266 views

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;

}

}

This topic has been closed for replies.

1 reply

Van Kurtz
Van Kurtz
Inspiring
July 11, 2012

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

convextech67
convextech67Author
Known Participant
July 11, 2012

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.

Van Kurtz
Van Kurtz
Inspiring
July 13, 2012

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.


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

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