-
Suggestion
-
Resolution: Duplicate
-
None
-
None
-
None
-
Atlassian OnDemand 5.0-OD-1
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
It would be really useful to control the column width for each table as well as the fonts used on the PDF export.
We know it's possible to achieve that by editing the CSS, but it will be applied through all the space, and that's something we wouldn't like to be applied to all the tables.
- relates to
-
- Closed
-
- Closed
[CONFSERVER-26386] As a user, I'd like to control the column width of a table and the font for each table using the PDF export
Karie Kelly
added a comment - We have several use cases where the PDF export was not presentable as customer-facing documentation due to not having this capability.
Example 1: First column is a feature description/summary and remaining columns are customers or versions where you are placing an X if they have it or not. You want the first column to be wider and the remaining columns minimized to accommodate the column header name, and that's it. Right now, if you have 10 columns, the first column contents then have words that break in the middle, wrapping, and it does not present well.
Example 2: The first column contains an icon, the second and third columns contain the location and description. Obviously, the first column is not large because it only contains the icon - but, when it takes up half or a third of the page width, it does not look good.
Instead of trying to always make it work for the user and assume what they want, put the responsibility back on the user to define the widths. If they don't define anything, then certainly allocate evenly. But, if they do define them, and if the table is too wide, they will realize it on export and allow them to make changes and take responsibility.
This is similar to the same request for columns. Currently, you can define multiple columns to display on a page; but, on export, the column formatting is ignored. Again, put the responsibility on the user. If they want it at 30%, then it takes up 30% of the width.
Karie Kelly
added a comment - We have several use cases where the PDF export was not presentable as customer-facing documentation due to not having this capability.
Example 1: First column is a feature description/summary and remaining columns are customers or versions where you are placing an X if they have it or not. You want the first column to be wider and the remaining columns minimized to accommodate the column header name, and that's it. Right now, if you have 10 columns, the first column contents then have words that break in the middle, wrapping, and it does not present well.
Example 2: The first column contains an icon, the second and third columns contain the location and description. Obviously, the first column is not large because it only contains the icon - but, when it takes up half or a third of the page width, it does not look good.
Instead of trying to always make it work for the user and assume what they want, put the responsibility back on the user to define the widths. If they don't define anything, then certainly allocate evenly. But, if they do define them, and if the table is too wide, they will realize it on export and allow them to make changes and take responsibility.
This is similar to the same request for columns. Currently, you can define multiple columns to display on a page; but, on export, the column formatting is ignored. Again, put the responsibility on the user. If they want it at 30%, then it takes up 30% of the width.
We already have an issue for this covered off by
CONF-3393.