I have the following issue. I am working with a milspec document. We are working with tables in flight manual context.
Our correct element structure for a table is as follow:
< Row >
< Entry> </Entry></Row>
The problem is when we run our conversion table on the legacy data, Frame is not putting the element "Tgroup" in the structure. The following is what we get after running our conversion table:
I wanted to write a script or macro that would correct the element structure for me. Any suggestions?
In your conversion table, you might try this:
|Header 1||Header 2||Header 3|
Alternatively, you could use XSLT on your converted XML to add the Tgroup wrapper. You could do this with a script, but I would try the other two methods first.
Remember that the structure used within FrameMaker need not be an exact match to that used in XML as long as when you can easily convert between them in the needed directions.
In particular, your XML structure uses the CALS table model, in which tables have five levels of structure:
2. Tgroup (that is, group of adjacent table rows)
3. Table heading, body, and/or footing
The FrameMaker table model, however has four levels:
2. Table heading, body, and/or footing
Note that the absence of tgroups in the FrameMaker model. CALS tables uses tgroups for blocks of consecutive rows. Rows in different tgroups need not have the same number of cells. If two tgroups do have the same number of cells, the column widths can differ in the different tgroups. Tables with more than one tgroup are very rare.
FrameMaker can automatically map between its internal table model and the CALS model in two ways. If your tables will never have more than one tgroup, you need not use the tgroup element in FrameMaker. As long as the table element is named Table (not Figtable), if you are saving to XML using a DTD that defines a tgroup element, FrameMaker will create the tgroup when it writes XML and will put information on column widths in the tgroup element rather than the containing table. If you may actually have tables with multiple tgroups, you can use a 5-level structure in FrameMaker. However, the top level will be a container rather than a FrameMaker table and the tgroup elements will be FrameMaker tables. The consecutive tgroups can be formatted with no vertical space between them.
There are two advantages to using FM's natural 4-level table model when you do not have to deal with multi-tgroup tables:
1. Since there are fewer elements, writers have fewer elements to manipulate and the Structure View is less cluttered.
2. FrameMaker automatically repeats any table title, heading rows, and footing rows on every page of a multi-page table. If you use a five-level model, the table element will be a container. If there is a table title, it will also be a container and will not repeat (although you can copy it to successive pages with a plug-in or script).
For a project like yours, the first thing I would do is analyze how the Figtable will be used. Does it always have exactly two rows (one for a graphic and one for a figure number and/or caption)? If so the 4-level model should be fine. Does the number of columns vary in different Figtables? Once, I had a good grasp of the requirements, I would see how close I can come using read/write rules to use a comfortable model in FrameMaker, import documents from XML (if the project requires import), and export valid XML documents (if the project requires export). If it is not possible to get exactly what is wanted selecting options with read/write rules, I would probably look at tweaking the XML with XSLT before considering a script or plug-in.
Thanks to everyone who answered. You input was appreciated. We will find another way to make it work.
You should check out FrameSLT, which allows you to automate tasks like this right in FrameMaker. It is useful for doing clean up after you run your conversion table. Here is a link to an article about FrameSLT on my blog: