Table sizes (Column widths, full table width)

[Ken Norcross]

Is there any way to force tables to always take up the full width of the page?

Also the column sizes I specify do not seem to be realized in the word document.

I find that I have to make a pass over the output document, to force all tables to use the full width of the page, to get the look that I want.

[eadocX Support]

When you specify the widths of the columns in a table, we try to show you approximately the total width. These are the column widths which we tell Word to use.
However, Word tries to “help” and sometimes changes these widths. Sometimes that’s useful, where a narrow column has some long words in it. Then Word will expand the column. But all attempts to fix the column width precisely have failed, and I’ve now given up. Word is just too “helpful”.

[Heather Wallace]

The column widths has been driving me to distraction too. There seems to be no rational on when Word tries to help. I have tables constructed in the same way in eaDocX on different stereotypes in the same document, same styles and table styles, same column widths. On one stereotype (a custom stereotype of Class) the widths are always output consistently and the requested cell alignment is observed (top), on other stereotypes (custom stereotypes of Activity) the column widths change for the contents and the cell text is vertically centred. Makes no sense to me at all.

I’m learning to ignore the detrimental impact it has on the documents. There are just too many tables to change them all individually, and Word doesn’t seem to offer the option of selecting all tables or all instances of a table style. If anyone knows how to multi-select tables in Word 2007 I’ll be forever in your debt!

Regarding table width, on my recent documents I’ve standardised on a total of 575 pixels across all columns, using a table style that centres the whole table on the page. Thus far all my tables are outputting at the same width (15.21 cm) in perfect alignment. It’s just slighly less than my margins, but looks fine.

[Ken Norcross]

Your reply got me to try wider total widths in eaDocX, we print mainly landscape orientation, and setting all tables to a total width around 875 is working well.

I didn’t realize I was setting things too narrow, I was fooled by the “wider than A4” warning, so total width is not really an issue for me anymore.

The cell alignment is still bothering me, we prefer mainly top alignment, but all I seem to get is center, even when set in the Word style, and when all options I could find in eaDocX are set to top.

eaDocX sets the Word style I specify, but the style seems only partially applied. In the doc I have to pick the style again, even though it is already set correctly to get the full effect.

You can manually multi-select tables in word by control-clicking them one at a time, and then in one go set the style. (select all for a style would help me also)

We are new to producing docs from Sparx. My original goal was to exactly recreate the hand produced Word docs, but I think over time we will slowly give up making a pass over the documents to recreate the old look. As we produce more and more documents from the model it will just become too much.

[Heather Wallace]

Ah yes,

I also find the Word table style is only partly applied, for example my offsets within the cells are not applied. I’d forgotten about “manual multi-select” of tables, I did use that at some time in the past. The trouble is that now we typically have circa 200 tables per document. So it may be appropriate for a final baseline publication, but wouldn’t want to do it every time.
Good luck with your experiments.

Heather

[Heather Wallace]

Another thought for you / clue for eaDocX
(extra info added)

On my current task I observe the following:
1 Tables that are simply output as a table of relationship attributes are complying with their column width definitions and text alignment in cell.
2 Tables that are defined in the same way, but are navigated to via RelationshipElement (to stereotype defined as table) are automatically resizing columns and using centred cell alignment.
Example structure:
Package
– FeatureGrouping (Object Type = Class) IS PARENT OF SystemFunction (Object Type = Activity)
– FeatureGrouping (Object Type = Class) IS PARENT OF Capability (Object Type = Class)
– SystemFunction (Object Type = Activity)IS PARENT OF SysUseCase (ObjectType = UseCase)

My FeatureGrouping profile outputs:
1. A table of the Name and Description of its SystemFunction children (WELL BEHAVED TABLE)
2. A relationship element (SystemFunction), which is defined to output inline only a table of the SysUseCase objects that have a trace relationship (mostly those in the tree but also some others) (BADLY BEHAVED TABLE)
3. A relationship element (Capoability), which is defined to output as a table (i.e. not inline). (WELL BEHAVED TABLE)

I will no doubt get further clues over the next few days, but thought this worth mentioning,

Heather

• This reply was modified 10 years, 8 months ago by Heather Wallace. Reason: Added exta info and clarification

[eadocX Support]

Thanks for this – I think I’ve found my mistake – slightly different HTML generation for the two different cases. Same was true for tables of Attributes & methods. Now fixed, and will be in next maintenance update later this week.
I will update this with the exact version number.

[Heather Wallace]

That’s great news,

I like playing the role of clue finder – especially when it results in a fix!

Heather

[eadocX Support]

fixed in 3.3.11.1, now available

[Author]

Posts