cells not recognised as being in rows

[FieryPantone]

b extract from xml

[tableRow]
[tableCell]Environment[/tableCell]
[tableCell]none[/tableCell]
[tableCell]4[/tableCell]
[tableCell]Operations[/tableCell]
[tableCell]Security[/tableCell]
[tableCell]none[/tableCell]
[tableCell]4[/tableCell]
[/tableRow]

b extract from EDD

Element (Table Row): tableRow
General rule: (tableCell)+
Element (Table Cell): tableCell
General rule: [TEXT]

b extract from r/w rules (validated against structapp)

element "tableRow" {
is fm table row element "tableRow";
}
element "tableCell" {
is fm table cell element "tableCell";
}

b message from parser

FrameMaker cannot insert the table cell (tableCell) at the current position. A cell must be in a table row.

b comment from me!

I can't see where the problem is coming from here :-{ (some more of your) patient help and explanations will be appreciated. While I'm waiting, I'll try replacing [TEXT] as the content for a tableCell with a new element.

[MarttiP]

Hi Niels,

You've faced the most common problem with tables in new designs..;)

This message is a result of following problem:

Frame needs to know the number of columns in the table. Without this info frame cannot arrange the cells to rows.

Usually this is stored in an attribute in the top-most element (typically either table or tgroup element) of the table. Standard table models, such as OASIS and CALS use "cols"-attribute for this. If possible, try to use these models in your DTD/schema, saves a lot of time and effort..

If your DTD/schema uses either of these models, check the "Structure_Dev_Guide.pdf" in online manuals (fm 7.2) to set the r/w-rules accordingly, there is a "out-of-the-box" rule set to use, you just need to decide whether your table uses table or tgroup element as root.

Tables are nasty beasts, you also need to consider spannings, table formats, rulings and column widths etc. It is wise to read carefully the developer guide's table chapter.

Martti

[_Van_Kurtz_]

Niels,

One of your problems is the format of your read/write rules for tables. In particular

element "tableRow" {
is fm table row element "tableRow";
}
element "tableCell" {
is fm table cell element "tableCell";
}

should be

element "tableRow" is fm table row element;
element "tableCell" is fm table cell element;

Here is what I use for my tables:

element "Table" {
is fm table element;
attribute "columns" is fm property columns;
attribute "columnwidths" is fm property column widths;
attribute "tableformat" is fm property table format;
}
element "TableTitle" is fm table title element;
element "TableHeading" is fm table heading element;
element "TableBody" is fm table body element;
element "Row" is fm table row element;
element "Cell" is fm table cell element;

Good luck,
Van

[FieryPantone]

Aha! yes, now you mention it I can see that I haven't explicitly told FrameMaker how many cells I'd like in a column; perhaps a pity it can't count for itself, but there you go <g><br /><br />Now to tidy up my r/w rules and read up on CALS tables ...<br /><br />N

[FieryPantone]

Worked like a charm! correct table style applied, cell-level formatting picked up through context rules ... but that was yesterday :-{<br /><br />This morning, same EDD, same r/w rules, same everything: and the table arrives as a table, with the correct table style, but not the cell-level formatting.<br /><br />Or am I confused, and did the context-rules never apply cell-level formatting? Farther advice always welcome <g><br /><br />N

[Russ Ward]

Niels, if you have paragraph formatting applied by the cell element (or even a higher table component element), it should be the default for cell text, unless overridden by a paragraph-containing child element. I think it's typically better practice to let all child elements do their own formatting, though. Takes some of the guesswork out of it. In any case, whatever you see on the page is what your EDD is doing. If it's not formatting right, you'll need to do some debugging.

Russ

[_Van_Kurtz_]

Niels,

Note that if your EDD sets some kind of general formatting (such as a body format) at a high level above the Table element, the elements inside the Table element do not "see" it. You need to define or redefine the general formatting in the Table element. Then all the elements inside the Table element pick up that formatting, unless particular elements change it.

Unlike Russ, I set the "table body" formatting in the Table element and deal with exceptions (such as table headings) in the appropriate elements.

I also do not put text in Cell elements. I allow Cell elements to have Paragraph elements, List elements, etc. This makes it easier to format lists inside table cells because the List element has probably already dealt with most of the formatting.

Van

[Lynne A. Price]

Niels,

To elaborate a bit on Van's comment, formatting set for ancestors is not inherited by tables or by footnotes. FrameMaker assumes that these constructs are formatted differently than text in a "regular" flow. Furthermore, the default formatting for tables and footnotes differs from that for body paragraphs. If your EDD has no relevant format rules:

1. 
   
2. Paragraph format Body applies to body paragraphs.
   
3. The paragraph format your document uses for footnotes (or table footnotes) is used for footnotes. Use Format > Document > Footnote Properties to inspect or change the paragraph tag.
   
4. The table format determines the paragraph format used for any table title and the cells in the table. In particular, when the table format was created or last updated, it stores the paragraph format used for any table title and in each column of the first row of whichever of the three parts of the table (heading, body, footing) exist. The stored paragraph format applies to the table title, and the paragraph format stored in the first column of the row in the relevant table part applies to all cells in that part of the table.

--Lynne