Skip to main content
A
Anonymous
April 19, 2011
Answered

FrameMaker -> XML -> FrameMaker issues

  • April 19, 2011
  • 3 replies
  • 3198 views

Hello,

I currently have about 150 pages fm file, which were orginally unstructured but I managed to make a working structure to it. It has mainly tables, which have crossreferences, images, graphics, inner tables and stuff, so about normal technical document. Reason why I'm structuring it and turning to XML is that we have some other XML file from where we will add data to this document and currently that is done by hand and we want to do it my machine. Those things are done by magic of programmers who can speak better c-related languages than English.

I can make XML from this fine, so that XML that is created is valid and structure looks like it is copied fine to XML. Inner tables, images and graphics are currently inside anchored frames as graphics elements, since they were something similar in unstructured document and read/write rules transform them to EPS images, since inner tables don't work as SVG, which I would otherwise prefer, because it is also XML and those anchored frames have some crossreference links to document's other parts. SVG would be also easier to handle in programming (or so I think) than EPS. If anyone can think better way to do these, I'm open for suggestions.

Issue currently is that when I open this created XML in FrameMaker, it first loads about half an hour (computer is Intel T2500 2GHz, 2GB RAM, XP Pro SP3 laptop and FM is version 10) and then shows 9 pages of error logs about "framemaker cannot insert the table cell (Cell) at the current position" and then document is shown as 600 to 1000 pages "masterpiece" where first 150 pages looks normal but after that first page is shown again and tables are shown like one column in page. One would suggest that if file is created by FrameMaker, FrameMaker would open it normally, but apparently that is not the case.

Read/write -rules look currently like this: (if it helps at all)

element "Table" {

     is fm table element "Table";

}


element "TableHead" {

     is fm table heading element "TableHead";

}

element "TableBody" {

     is fm table body element "TableBody";

}


element "Row" {

    is fm table row element "Row";

}

element "Cell" {

    is fm table cell element "Cell";

}


element "HRef" is fm cross-reference element "HRef";


element "Row" {

     is fm table row element "ROW";

}


element "Cell" is fm table cell element "CELL";


element "Graphic" {

     is fm graphic element;

     writer anchored frame {

          export to file "$(entity).eps" as "EPS";

          specify size in pt;

     }

}


element "Equation" {

     is fm equation element;

     writer equation export to file "$(entity).eps" as "EPS";

}

There are some things that might look weird for some people. There are some conditional text in FM file and without rules like

element "Cell" is fm table cell element "CELL";

XML wouldn't be valid against DTD.

I would appreciate any help. I can also provide some other files here, but due NDA reasons, real document is No-Go, but I think if structure is needed to see, DTD is fine.

This topic has been closed for replies.
Correct answer Lynne A. Price

Ian, Russ,

  As you both no doubt know, it is perfectly acceptable to have multiple read/write rules for an element type. In this case, the rules include:

element "Row" {

is fm table row element "Row";

}

element "Row" {

is fm table row element "ROW";

}

or

element "Cell" {

is fm table cell element "Cell";

}

element "Cell" is fm table cell element "CELL";

The first pair of rules tells FrameMaker that when it is creating XML, FrameMaker Row and ROW elements both are output as XML Row elements. The second pair of rules say that FrameMaker Cell and CELL elements both are saved to XML as Cell.

When there are multiple relevant mappings, FrameMaker uses the first to appear in the r/w rules. When it is reading XML documents using these rules, it could map an XML Row element to either Row or ROW and a Cell to either Cell or CELL. Since the mixed case version of both rules appears before the all-caps version, when reading XML, it creates FrameMaker elements with the same name as the XML names.

Ejlamsa,

  Does your FrameMaker EDD have both Row and ROW (and Cell and CELL)? If not, you can remove the rules for the element types you do not use.

As far as the error messages and incorrect document you receive when you open XML, Ian is quite correct that FrameMaker must be told how many columns there are in the table. If your DTD does not yet provide such an attribute, the simplest solution is to add one. It is possible using a plug-in or script to create columns as needed, but that is significantly more effort.

     --Lynne

3 replies

A
Anonymous
April 28, 2011

Hello,

And thanks all the fast responses, I'm not doing this project full time, so I don't immediatelly response.

Adding attribute cols helped, now tables are drawn more correctly even when XML is opened again at FrameMaker, there are still some issues, but I think they can be fixed in some similar way adding attributes.

Now next big problem is tables inside tables (and some graphics, but I think I'll go step by step...). Now they are anchored frames (they were those already on unstructured file) and transformed to EPS like all the other anchored frames. Of course this EPS transform loses some information like cross references and those inner tables look very poor after transformation.

Could it be possible with some read/write-rules or otherwise to make these inner tables to be their own xml-files or even fm-files or do I need to change structure so that those tables are just child nodes of that column where they now are in anchored frame?

A
Anonymous
May 3, 2011

Apparently graphics issue was solved easier than I thought. That MIF-file Framemaker offers, uses apparently some markup language format and is actually just text file, which keeps struckture after xml is opened again at Framemaker. Before I didn't use it because I thought it to be some Framemaker binary format. I think I end my questions here for now and thank you all for co-operation.

E-J

L
Lynne A. PriceCorrect answer
Inspiring
April 26, 2011

Ian, Russ,

  As you both no doubt know, it is perfectly acceptable to have multiple read/write rules for an element type. In this case, the rules include:

element "Row" {

is fm table row element "Row";

}

element "Row" {

is fm table row element "ROW";

}

or

element "Cell" {

is fm table cell element "Cell";

}

element "Cell" is fm table cell element "CELL";

The first pair of rules tells FrameMaker that when it is creating XML, FrameMaker Row and ROW elements both are output as XML Row elements. The second pair of rules say that FrameMaker Cell and CELL elements both are saved to XML as Cell.

When there are multiple relevant mappings, FrameMaker uses the first to appear in the r/w rules. When it is reading XML documents using these rules, it could map an XML Row element to either Row or ROW and a Cell to either Cell or CELL. Since the mixed case version of both rules appears before the all-caps version, when reading XML, it creates FrameMaker elements with the same name as the XML names.

Ejlamsa,

  Does your FrameMaker EDD have both Row and ROW (and Cell and CELL)? If not, you can remove the rules for the element types you do not use.

As far as the error messages and incorrect document you receive when you open XML, Ian is quite correct that FrameMaker must be told how many columns there are in the table. If your DTD does not yet provide such an attribute, the simplest solution is to add one. It is possible using a plug-in or script to create columns as needed, but that is significantly more effort.

     --Lynne

A
Anonymous
May 3, 2011

There are no CELL and ROW on EDD, those rules are on file just to keep those error messages away, because they annoy me . I'm not sure though if framemaker is able to create or open created XML if those rules are left out. After putting that Cols-attribute and some rowspan and colspan attributes to document it started to look much better.

Ian Proudfoot
Ian Proudfoot
Legend
April 19, 2011

ejlamsa,

The read/write rules are ambiguous for the Cell and Row elements. You are mapping to 'Cell' and 'CELL', Row and ROW. This could be giving you the error messages. As for the duplicated content, that is more difficult to understand without seeing the XML. If you want to post it on this forum you could do a find and change to garble the text content. A look at the DTD and EDD would also be useful.

For the nested or 'inner tables' you could try exporting as MIF which could reinstate the original table and cross ref functionality. Although I've not tried this recently.

Ian

A
Anonymous
April 19, 2011

Like I said, without those ROW -> Row, CELL -> Cell, I would have invalid XML according to DTD, but I need to check that again.

DTD is

<?xml version="1.0" encoding="UTF-8"?>

<!--DTD for Chapter. Typically invoked by
      <!DOCTYPE  Chapter  SYSTEM struct.dtd">
-->

<!--April 4, 2011-->

<!ELEMENT Chapter    ((Title, Section+) | Body) >

<!ELEMENT Title      (#PCDATA | XRef)* >
<!ATTLIST Title      Id        ID        #IMPLIED >

<!ELEMENT Section    (Title, (Para+ | Table)) >
<!ATTLIST Section    Id        ID        #IMPLIED >

<!ELEMENT Table      (TableHead?, TableBody) >
<!ATTLIST Table      Type      CDATA     #IMPLIED >

<!ELEMENT TableHead  (Row+) >

<!ELEMENT TableBody  (Row+) >

<!ELEMENT Row        (Cell+) >

<!ELEMENT Cell       (#PCDATA | Para)* >

<!ELEMENT Para       (#PCDATA | HRef | XRef | CRef | Hypertext | Graphic
                              | Bold | Emphasis | ConditionalText | Equation |
                              Subscript | SmallCaps | Para)* >
<!ATTLIST Para       Type      CDATA     #IMPLIED
                     Id        ID        #IMPLIED >

<!ELEMENT HRef       EMPTY >
<!ATTLIST HRef       Type      (head|pageno|paratext)  #REQUIRED
                     Idref     IDREF     #IMPLIED
                     format    CDATA     #IMPLIED
                     srcfile   CDATA     #IMPLIED >

<!ELEMENT CRef       (#PCDATA | HRef)* >

<!ELEMENT XRef       EMPTY >
<!ATTLIST XRef       type      CDATA     #IMPLIED
                     text      CDATA     #IMPLIED >

<!ELEMENT Hypertext  EMPTY >
<!ATTLIST Hypertext  type      CDATA     #IMPLIED
                     text      CDATA     #IMPLIED >

<!ELEMENT Graphic    EMPTY >
<!ATTLIST Graphic    entity    ENTITY    #IMPLIED
                     file      CDATA     #IMPLIED
                     dpi       NMTOKEN   #IMPLIED
                     rasterdpi  NMTOKEN   #IMPLIED
                     alt       CDATA     #IMPLIED
                     impsize   CDATA     #IMPLIED
                     impby     (ref|copy)  #IMPLIED
                     sideways  NMTOKEN   #IMPLIED
                     impang    CDATA     #IMPLIED
                     xoffset   CDATA     #IMPLIED
                     yoffset   CDATA     #IMPLIED
                     position  NMTOKEN   #IMPLIED
                     align     NMTOKEN   #IMPLIED
                     cropped   NMTOKEN   #IMPLIED
                     float     NMTOKEN   #IMPLIED
                     width     CDATA     #IMPLIED
                     height    CDATA     #IMPLIED
                     angle     CDATA     #IMPLIED
                     bloffset  CDATA     #IMPLIED
                     nsoffset  CDATA     #IMPLIED
                     insetdata  CDATA     #IMPLIED
                     posterfile  CDATA     #IMPLIED >

<!ELEMENT Bold       (#PCDATA) >

<!ELEMENT Emphasis   (#PCDATA | Graphic)* >

<!ELEMENT ConditionalText 
                     EMPTY >
<!ATTLIST ConditionalText 
                     type      CDATA     #IMPLIED
                     text      CDATA     #IMPLIED >

<!ELEMENT Equation   EMPTY >
<!ATTLIST Equation   entity    ENTITY    #IMPLIED
                     file      CDATA     #IMPLIED
                     position  NMTOKEN   #IMPLIED
                     align     NMTOKEN   #IMPLIED
                     cropped   NMTOKEN   #IMPLIED
                     float     NMTOKEN   #IMPLIED
                     width     CDATA     #IMPLIED
                     height    CDATA     #IMPLIED
                     angle     CDATA     #IMPLIED
                     bloffset  CDATA     #IMPLIED
                     nsoffset  CDATA     #IMPLIED
                     dpi       NMTOKEN   #IMPLIED
                     alt       CDATA     #IMPLIED >

<!ELEMENT SmallCaps  (#PCDATA) >

<!ELEMENT Subscript  (#PCDATA) >

<!ELEMENT Body       (Table | Para)+ >

I'll check how EDD is easiest to put here so that it is still understandable and also that XML without actual content.

R
Russ Ward
Legend
April 19, 2011

ejlimsa,

Ian is trying to tell you that you have conflicting rules. For example:

element "Row" {

    is fm table row element  "Row";

}

...and then later:


element  "Row" {

     is fm table row element  "ROW";

}


Element names are case sensitive, so "Row" does not equal "ROW".  Your DTD says "Row". I see no need for the "ROW" line and like Ian said, it might be the source of the problem.

Russ

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