After almost 5 years and 232 votes I'm resolving this issue as 'Fixed'. A new and improved pdf export is now complete and available as part of Confluence 3.0.

You can try it out by downloading the release candidate from http://www.atlassian.com/software/confluence/DevReleaseDownloads.jspa , and discuss the new pdf export with us at http://confluence.atlassian.com/display/CONF3BETA/Home. You can find some preliminary documentation on the new pdf export at http://confluence.atlassian.com/display/CONFEXT/Improved+PDF+Export+Documentation

Sorry it took so long and we hope it meets your needs. If not, please let us know. We expect to refine it based on your feedback as we look forward to the next release.

Really glad to see that we are improving the PDF Export! I had a whole slew of feedback to provide on this, so instead of commenting here, I created page detailing my thoughts here: http://confluence.atlassian.com/x/KIHjCg .

The biggest missing piece is the ability to define multiple PDF documents that can be exported from from within a single space, where each PDF document can have its own title page, header, footer, stylesheet, and specific set of pages. The reasoning, and a lot more detail is listed in the link specified here.

Looking forward to the next version!

Yes, with our current feature set, you could add as many pages to the front of the document as you want.

I am one of doc leads at Sun currently using Confluence. Having a more robust PDF export solution is becoming a must have.

I understand you'll be able to add a title page with this new feature. Will you also be able to add additional pages such as a copyright page? This is a feature that we need.

-Paul

Hi Everyone,

We have a new PDF export engine in the latest milestone (m6) of Confluence 3.0. It allows you to use CSS to customize the PDF export. It also has built in support for things like table of contents, headers, footers, and a title page. (for space export). You can get the latest milestone here. Also there is documentation for the new PDF export here. This feature is still in development and we want your input. Thanks

-Ryan

Just adding more resources isn't the problem, it is more one of priority.

The good news is that although we can't promise a delivery release (we never do, unless we have already built the feature for a particular release and it is well tested and certain for release) we have started looking at the PDF Export problem in both ShipIt projects and it has been tentatively scheduled for investigation in our roadmap for the next year. It isn't a trivial problem however and there is a large risk component.

I have to agree with John. Charge more then. Actually I wish you would allow sponsoring like many open source projects do. There are about 10 things in Jira and Confluence that would make my companies (and my life specifically) much much easier. I know I could get some money to through at these, and if others did the same, then you could get resources to do the work. I don't want to contract a 3rd party, I want it in the system, and confident that it is being maintained from version to version. If I am willing to pay extra for it, obviously it is mission critical and don't want to have to worry about it being kept up to date.

We want to use Confluence for documentation. We need three features: Copy hierarchy, PDF printing working better, Print hierarchy as one document in PDF with the ability to designate a page as a table of contents, Chapter, and Subsections, etc. I am sure I could get $500- $1000 to put in a sponsorship fund. If 20 other customer also added to the kitty, you would have your funding to complete the work in a timely fashion. I am prepared to vote with more then a mouse click, but with cold hard cash!

From my understanding it will also require some input from existing plugin developers. Third party macros (of which many are now bundled with Confluence) will in many cases need to output something slightly different when the content is exported to a PDF.

I know that Atlassian added something that allows a macro to know (at least to some extent) that it's output is being exported and there are additional improvements where macros can ask Confluence to cache temporary images (e.g chart macro or gliffy diagrams) so they can be included in a PDF export, however it would probably be useful to have some specific page aimed at plugin developers that explains what they (we!) need to do in order to have our macro output look nicer in PDFs. Currently I believe there are several resources dotted around the c.a.c site so if they could somehow be combined or at least linked to from a central page that would help.

Working in the commercial software business, I'm sympathetic to the often no-win challenges of prioritizing your resources to developing certain features and addressing certain defects. Usually, adding more developers (and consequently more testers, etc.) actually doesn't directly translate into more overall productivity – a sad but true reality in this biz.

Regardless, for my part, as a developer who also helps others deploy wikis, I'd be incredibly happy if Atlassian were simply to put some work into making it easier for others to extend the Confluence export-to-another-format capability, either through some more developer documentation, samples, or published API.

Now, to be clear, I confess that I haven't gone looking deeply to determine whether the current version of Confluence is well enough equipped to allow custom development for the purpose of enhancing the export feature. Some time ago I did briefly look at it, and came to the understanding that while it looked possible, it practical terms it wasn't. I got my hopes up when I found out that Confluence uses XSL:FO, and while XSL:FO can be a real challenge to work with, at least it is something. But I learned that Confluence wasn't really setup to permit one to substitute a separate set of XSL stylesheets, that the PDF export process wasn't just implemented with an XML->XSL->PDF process but was coupled to the Confluence Java code driving the process. Again, maybe things have improved, but I haven't looked into it lately. If I can be enlightened or corrected into believing that it is straightforward to enhance the PDF publish process without having to hack Confluence code (i.e. instead of hacking code, providing a plug-in or something similar), I'll be thrilled.

So, summing up, in the absence of a better PDF publish capability, I think Atlassian and its customers would be at least better off to have a mechanism for Confluence to simply export its XML content and hand it off to an extension or plug-in of some sort that could then transform that XML to a particular format. Let the third-parties provide solutions in the interim. Even if/when Atlassian provides a better PDF publish capability, chances are it is only going to please 50% of the people, at best, so a solution that permits third-party solutions to me is better all round.

I'm a developer, I know XML, I know XSL-FO, and I know PDF. If I thought I could scratch my own itch for a better PDF solution, I'd most likely do it. So, I'd vote for Atlassian making it more viable for third-parties to address this issue, so that at a minimum I can address my own needs, or use a third-party solution.

However, we have a limited number of developers and a limited amount of time; we also have other priorities that we have to work on first. For example, in the next release, Confluence 2.8, we are implementing the issue with the most votes, Page Ordering (CONF-1031). We can't work on everything at the same time.

Nine months???, This is my last post on this topic.

Guys I remember that your commercial dept. doesn't sell your product as school wiki but as enterprise wiki
Given that in all your demonstration media shows incredible and attractives pages, I would like that someone at Atlassian would explain us how to export them. Or more likely how our enterprise employees export their docs for a meeting.
Should they bring a monitor?

A close tool is not an enterprise tool