Nested tables

[Rsfl]

Hi all,

there is some Information in the Framemaker help how to nest tables in structured documents but I simply don't understand how to implemend this. This is a DITA document and I know that nesting tables is very bad style. However it is a requirement and after all DITA does support it.

In unstructured documents we used anchored Frames in table cells. The approach for structured documents seems similar:

"Select a graphic element for empty anchored frames in the Element Catalog, and click New Frame"

I wonder how I can accomplish this. In the EDD I would have to set up an element (perhaps a dedicated paragraph class) to insert an anchored Frame in which then the table is inserted.

Has anybody succeeded in using nested tables in structured documents with Framemaker?

Robert

[ScottPrentice]

Hi Robert...

I don't think that it's possible without some serious FDK or ExtendScript work.

As far as I know the only way to "nest" tables in FM is to use an anchored frame within a table cell. The content within an anchored frame is technically in a separate flow. The standard XML export only processes a single flow. You'd somehow have to merge multiple flows on export, and create multiple flows on import. This sounds like a really bad idea .. if this is really a requirement, I think you're going to have to use a different editor.

However, if the nested table's structure is simple, you could instead use a list structure while in FM, and set up an XSLT import/export that converts that list into a table and back.

Personally, I'd revisit that requirement .. I think you're probably going to run into trouble in many places.

Cheers,

…scott

[Rsfl]

Hi Scott,

thanks for the Feedback. Regrettably we cannot change the requirements in this case.

The Framemaker guide does sound like it is possible with some tweaking: "If you export a document to SGML or XML, you can lose the contents of anchored frames in it because they are not part of the main structured flow. Work with your application developer if you plan to export to SGML or XML to avoid losing data in the nested table."

I had  hoped that there might be a workaround, but what exactly the application developer is supposed to do is not mentioned there.

BR,

Robert

[ScottPrentice]

I'll ask on the FM dev list that I'm on, but I'm not aware of any nested table options. As a FM developer myself, I can "imagine" ways to do that, but it would cost a bit of change to get such a plugin developed. This would not be just some simple "tweaks".

Your statement that "DITA supports nested tables" is technically correct, but I think if you ask around you'll find that this is generally considered a bad practice. The "support" is really more of a workaround than true support. You can insert a table within a <p> that's in a table cell, but I think that this isn't the real intent. I would try to use an alternate structure that emulates a table-like structure rather than using a real table.

…scott

[ScottPrentice]

Hi Robert...

I'm not hearing that anyone on the developer's list has any ideas about supporting nested tables. There were suggestions for "simulating" this through the use of straddles, but that can get rather complex. You can also "fake" it with spaces or tabs. You could also use a special list structure within each cell that is formatted in a columnar fashion.

If you really want to be able to have nested tables, you'll likely need a custom FDK plugin. If you're looking for someone to do that work, I'd be willing to talk to you more about this off-list to nail down your requirements and provide a quote for the work. You can contact me at <info at leximation dot com>.

Cheers,

Scott Prentice

Leximation, Inc.

www.leximation.com

[Rsfl]

Hi Scott,

I'll find out about that thanks for the info. This is about migrating legacy documents that use nested tables in abundance. Actually the old HTML output looked fine so the requirement is to "just keep" the existing structure wherever possible. I would normally refrain from using nested tables. I have already simulated two-column tables but for more complex structures real tables would be needed.

BR,

Robert

[Gorly]

Hello Robert,

how about solving the issue mimicking those tables?

If you work with col- and rowspans, you might be able to create a second "table" within your first.

This is actually quite ugly as a solution, but it should work at least.

The nifty part on it would be the XSLT transforming any nested tables into proper spans.

If you use 3 rows and 3 columns as a "standard grid", you could also mimic the spacing around the nested table.

The central cell of this grid would then serve as the container cell for the "nested table".

Not exactly best practice - but should solve at least your legacy problem (the other solution would be to simply ignore the fact it doesn't work and find a solution that looks a bit like the legacy document).

-Alex

[Rsfl]

Hi Alex,

thanks for the idea - I'll look into that. This solution would not be very nice to work on for the authors, regrettably this content will see a lot of future maintenence. Otherwise we would just pack the tables into p elements knowing that they will render to HTML all right but you cannot open them in Framemaker anymore.

Robert

[Gorly]

Hi Robert,

ok, I see where that one's coming from now.

One or two more questions though:

Are we talking about fixed pages here (as in product information sheets or booklets)?

Or are we talking about flowing text within longer documents, containing those tables?

Are those tables layout constructs or do they contain data that is tied together?

If one of those questions answers with yes, I might have some more ideas to work around it

-Alex

[Rsfl]

Hi Alex,

this is a set of XML files that are used to generate HTML output (one page per file). No print is generated from this. Tables can be located on the same level as paragraphs. I am not sure what you meant with fixed pages, does this info help?

Sometimes nested tables were just layout constructs, I already did away with them. The problem are nested tables that are actual tables (often with 5 or more columns, containing for example a matrix of parameters and the meaning of different values).

Robert

[Gorly]

Hi Robert,

this does actually help me a lot, as the situation is like I already suspected, when you mentioned HTML.

The solution might actually be to do the layout limbo.

Simply create several different "table" template pages that mimic those tables you are encountering.

Then set up a grid of text frames using the same flow and add some lines around them.

Those will be of fixed size, but that shouldn't bother your authors much.

Within those "table cells" you're free to add new tables if needed.

Structure wise, you're simply having a plain XML in the background that can be translated to HTML using standard procedures.

If you then add an attribute to the first element of the "table page" you could even control the template pages used automatically.

This is all about "Tarnen und Täuschen" (sorry for using a German saying here - Robert understands this).

Hope you get my idea behind it

-Alex

[Rsfl]

Hi Alex,

I will look into that thanks! Maybe the English speakers will understand "duck and cover" better - sort of duck away from the XML validator and cover ugly content to look like DITA  ; )

Robert