 |
Note the following:
• It is the table itself that is rotated — this includes its rules and contents but does not include the margins around it. Any nested content will be rotated entirely, however, which does includes its margins.
• For 90° rotations, width and depth are essentially flipped so the table will overflow when the width is exceeded. It will then flow automatically to the next column in the parent container.
If an outer table is set to measure the width of its columns it will be unable to do so if the content includes a table that is rotated by 90° This is because the prescan is expected to determine the width without a known width being available, and since the width of the table now forms its depth, as the table is rotated, the action can’t be completed.
• For rotations set with num=1 or num=3, the resulting width will be unpredictable if the table doesn’t have a fixed width set. It effectiveness will depend on how far down the page the definition occurs.
• A table that is rotated by 90°, and whose width fills out to the measure, will fill to the bottom of the parent container. It is therefore incompatible with using either a column or row footer on a parent table or block, because there will never be the space available for it.
• Vertical justification will not have the expected effects
• It is no longer logical to apply a break across columns property to a rotated table via the <?tbacross> command.
|