I've tried every combination of fixed, auto, and specific %s for the following code:
table-layout: fixed !important;
width: fixed !important;
...each in combination with test tables that, in the Confluence editor, are selected to be either "Fixed width" or "Responsive" from the menu, and contain small to large quantities of text (to force column widths to expand/contract, if they are not responding to the "fixed" commands).
I have found no combinations of this that result in a predictable, let alone WYSIWYG, output to PDF. This seems like a massive Confluence bug since CSS is validating correctly on https://jigsaw.w3.org/css-validator/.
Before I waste any more time,
(1) has ANYONE found a solution to this that does NOT involve a 3rd party plug-in?
(2) if you get WSIWYG tables using a plug-in, which one and do you recommend it?
Reminds me of this thread: https://community.atlassian.com/t5/Answers-Developer-Questions/Documentation-PDF-export-a-la-Atlassian-s/qaq-p/486060 where Robert mentions they use https://itextpdf.com/en. Baybe this will help.
Hi Laura and Matt --
I haven't done PDF output in a couple years now, but I think my best solution with table column widths was this:
* Use Scroll PDF Exporter
* Use the "Scroll Table Layout" macro (one per table in the Confluence pages) to define relative column widths (e.g., "20%,80%" "25%,25%,50%", etc)
Thanks, @Matt Reiner _K15t_ . That's good to know about itextpdf.
@Sharon Metzger thanks, that sounds perfect for some folks who may be looking for this answer and already have Scroll PDF Exporter! It sounds like a great tool for some users who can afford it; numerous folks have recommended it for solving all kinds of bugs and short-comings in Confluence's built-in functionality.
Unfortunately, Scroll PDF Exporter would cost multi-$thousands/year on top of a multi-$thousand upfront cost. This is right out for my tiny department's needs, and even so manually defining the percent of each column in each table is wayyy beyond reasonable for a tool that expensive: it would be far cheaper for us to hire a temp to retype the docs on a Smith-Corona then scan to PDF every time we do a release if that needed to be manually adjusted and tested for each table: that would be a pain almost equal to my current situation with the default Confluence random output. Hours of testing for constantly changing table content is impractical.
Does anyone ( @Sharon Metzger , @Robert Lauriston , @Nancy Hutson Ha ) know what controls the outcome in the PDF? I can detect no particular pattern that I can document for my users, but there obviously is one. (Hours of painful testing is in my near future if nobody knows this; I'm hoping that Atlassian responds to this directly.) I'm astonished that Confluence/Atlassian doesn't have that basic out-of-the-box functionality documented.
Even remotely WYSIWYG should be possible; this is a massive feature-gap in Confluence.
Yes, I understand I didn't address your needs, unfortunately, just responding to Matt's callout. But I feel your pain, and table formatting is one of the reasons (page breaks is another) I abandoned native PDF export for Scroll PDF export, and eventually abandoned PDF entirely.
(I use Scroll Viewport now for delivery, on a separate Confluence instance with the minimum license tier.)
I see from Inspecting a Confluence page in a browser that tables use role="grid", role="row", etc. I'm not familiar with the role element, but wonder if those bits are complicating PDF exports? Not that I have any idea what to do with that.
@Sharon Metzger , wow, good catch, I'll look into that about the "role" tags: sorry I didn't catch that myself. Thanks much! I do think your answers will help many folks who can afford the Scroll PDF Exporter pricetag. :-)
I wish Confluence would just use and parse standard, validating CSS, like they're supposed to per W3C. If they're going to go against the WWW standard, they should really provide docs indicating what their mods are. Customer-provided documentation development is an indefensible business model, but I encounter it often these days.
I'll post an update here if I find a solution or decode the Confluence business logic. Thanks again!
To fix some column width when exporting my pages to PDF, the simplest way I found was to put a « white » image to fix the length of the column. In the PDF document the image will force the min-size of the column to the size of the image.
It's a simple fix, but it saved my ass multiple times!
Thanks, @Robert Lauriston . I'm just focusing on getting Confluence's basic functionality to work. I'll troubleshoot the existing tables and iterate to solutions for the content we have. I'm getting no responses from Confluence at all on this, unfortunately, so apparently they are ignoring the issues with their PDF export functionality.
Scroll PDF Exporter is simply not an option due to its price. The installation and licensing options were apparently researched thoroughly, and the implementation is too expensive by tens of thousands of dollars. Myself, I hesitate to invest more dollars and time in any stop-gap solution such as purchasing a plug-in or add-on software that attempts to patch expensive, high-end yet sub-optimal software to begin with. Good money after bad, as they say.
What Robert is pointing out is that if you can set up another instance of Confluence, the PDF Exporter is only USD10/year for up to 10 users. (A Confluence Server instance is also USD10/year for up to 10 users.) It's relatively straightforward to export Confluence files from one instance and import them on another.
Also, I hear you about preferring to avoid add-ons, but honestly, life with Confluence got much easier once I embraced the fact that people like those at k15t and Comala Tech were fighting the good fight for me -- using Confluence add-ons is good and necessary if you're going to use Confluence as any kind of professional publishing platform.
Atlassian has de facto outsourced to K15t all the things you need to create, maintain, and publish technical documentation. They're not going to put any resources into adding or improving native features that duplicate what you can do with Scroll plugins. There has been no significant improvement to the native PDF export in years.
I did understand Robert, but as I say the Scroll PDF Exporter licensing has been thoroughly researched and found to be prohibitively expensive by thousands for my company. I'm not sure why my company is being given a price so different from yours, but that is a closed issue.
Wish me luck, as I'm obviously going to need to do some creative work to create PDFs from Confluence without the Scroll PDF tool.
I am dismayed, however, to hear that Confluence bugs in what they do output to PDF (and non-compliance with W3C rules for CSS and HTML that cause the nasty PDF results) will not be addressed by Atlassian. That's irresponsible and expensive for all Confluence customers, but so be it. Obviously this has been the case for years and the community lets them get away with it and companies sprouted up to take up the slack for their failure.
Thanks very much for your help. :-) Happy Wednesday!
Whoever "thoroughly researched" Scroll PDF Exporter pricing clearly didn't consider the option of using a separate instance. As Sharon said, you can get it for $20. You can even install it locally on your PC or Mac and treat it like single-user software.
Confluence has been successful in large part because Atlassian supported plugin developers and promoted the growth of the plugin marketplace. No one company could possibly provide all the features you can get from the marketplace.
Atlassian "eats their own dog food" as far as the crappy native PDF output, though they use Scroll Versions and Viewport.
@Laura Schneider, when you come up with a solution, be sure to use that handy: "Provide feedback about this article" link at the bottom of the doc page to share it. I know the Confluence team really wants to have thorough and accurate documentation.
@Kevin Marlowe Thank you so much for sharing your code! Regrettably, this doesn't help me, however. I've been testing versions of this for a few days now, on and off. And so my search continues. Thanks for your help, however, as this might solve someone else's problem!
Here's what I'm seeing...
The code you provided causes the following on my system:
Line 1) table-layout: fixed !important;
This code seems to be ignored regardless of the table composition/appearance in Confluence and regardless of whether I include your second line (below). It /should/ work, I think, but it doesn't seem to be.
Line 2) width: 98% !important;
This code causes all tables to be 100% of the PDF page width, with equally sized columns, regardless of the original size or content of the cells in the columns. Example: A table with a column containing a single character, "X", is the same width (49%) in the PDF as a column containing "supercalifragilisticexpialidocious test test test test test test test test test test test test test test test test test test test test test test test test test", which is clearly not what I want.
So, what I'm seeing is that, when text wraps in cells in the Confluence text editor, this command causes my table columns in the PDF to end up scaling out across the PDF page to some relative width that allows the text to wrap, up to 100% of the available CSS-defined page width. Some columns come out way too skinny with odd text wraps, some come out oddly too wide. They do not stay proportional to the original table's appearance in Confluence, either. This is highly undesirable. I cannot, for example, get one table column to avoid wrapping a column of dates at the "/" mark, although there is plenty of room on the page. That last seems to be a character issue as much as anything, but it is similarly frustrating with simple numbered rows in a table, for example part numbers and descriptions of the part.
I've tried manually editing the HTML to set the width at a particular px in the confluence editor, but that did not translate to the PDF either which surprised me. Still investigating and testing manually editing this, however, and working with the CSS controls.
It seems like the Confluence "Export to PDF" generator function might be non-compliant with W3C--or it is being overridden by something--when it comes to creating the PDF file based on my CSS, however. I say this because literally printing the Confluence page and saving it as a PDF (CTRL-P using the "Adobe PDF" printer driver or the "Save as PDF" option) creates a more reliable PDF file with respect to the layout of the tables. I would use this, except that it includes all of the headers, footers, and default graphic stuff that you need to use the Confluence content but that is inappropriate to print, and it prevents you from using CSS to create the headers and title page and other things.
You can get 30-day free trials of Confluence Server and Scroll HTML Exporter, install them locally, export your content from the main instance, import it into the local instance, and get your PDFs to look any way you like.
If you're happy with that, it'll cost $20 to use that solution indefinitely.
You're not creating any shareholder value by extended experiments proving that Confluence's native PDF export sucks.
- Create your own custom emoji 🔥 - "Shake for Feedback" on mobile 📱 - An endless supply of GIFs via GIPHY 🤩 Is there anything quite as nice as a pleasant surprise? Comment below with what...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events