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.

I didn't realize you were so strapped for cash.

Why not charge more? No, I'm not kidding; I'd rather pay more for a product that I know has a decent development schedule vs. an inexpensive one that rarely has popular issues addressed.

We hear you. We recognise that issues with Confluence's PDF exporting is causing a lot of users pain.

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.

Unfortunately we have no current plans to work on PDF exporting and formatting. We will revisit our plans in 9 months time.

This is not the end of the road however. We will look at the different parts of this issue (especially the bugs) and see what could be a smaller, more achievable selection that we can reasonably achieve. To do that effectively, we would really appreciate comments about what the most important parts of this issue are for users.

Probably this is the most ugly bug and unresolved problem in Confluece.
Actually the worst thing is that Atlassian doesn't seems to have the will to take care of this and no official word has given to his customers.
And they write Legendary service!

Any news on this Item? It's very bad to need to use other editors like MS Word to format pages for printing.
If this item be implemented I would have a stronger case for using confluence as a main knowledge system in my Company.

We have a similar request in our company - Adtech. Our external customers need to be able to log on to wiki, click a link in a content page and have the right page of the user gude.pdf open for them. It would be great to be able to link from a wiki page to pdf headers/bookmarks/links inside an uploaded pdf document

With so many new releases of Confluence all the time, we're permanently swamped with upgrading our plugins to handle the latest API changes.

Maybe they should think about having a system like eclipse using a smaller but more solid core (platform with an API and extension points) that only changes once every year or so. Mayor features being implemented as plugins or plugin sets having their own lifecycle.

I'm pretty sure Confluence already tells macros what they are being rendered out to (can someone confirm?) but I think it's more a case of macro authors not having had chance to implement the features. With so many new releases of Confluence all the time, we're permanently swamped with upgrading our plugins to handle the latest API changes.

Certain navigation macros should NOT be rendered by PDF export or need better control... for example the {scrollbar} macro will show navigation to pages that you don't export

This is a page containing a simple table and the messy unusable pdf generated by confluence.

I worngly duplicated the comment, please discard this.

Fully agree! Sad story!

I actually stopped recommending Confluence as a product to friends and business contacts due to the poor performance of Atlassian in this issue and in CONF-1031

I echo the previous comments. PDF export is very important for our customers. The path for PDF export is currently very difficult. In fact, I've recently opened this issue: https://support.atlassian.com/browse/CSP-13377 - supporting different fonts should be trivial, however it's proving to be very problematic.

Same opinion. Atlassian needs to come into the picture regarding the pdf export issue. It is becoming as an obstacle for gaining acceptance.

Agreed. I suppose that playing with Adobe proprietary PDF format can be a mess - even Adobe itself can't make its own PDF tools bug-free - but I suppose this request would benefit from a formal discussion by Atlassian's marketing team: many clients are considering this as a critical factor for buy-in (especially that Confluence often creeps into companies from a Technical Documentation/Publishing platform before being used by other departments.)

It's unfortunate that it takes 3rd-party developers writing plugins to help us users with such an obviously important "core" feature

It's really a big mistery for me.
This should be a real core feature for a product that define itself "Enterprise wiki" . I wrote also on foum with no reply.
IMHO this silence is very embarassing.

It's unfortunate that it takes 3rd-party developers writing plugins to help us users with such an obviously important "core" feature.

Could someone from Atlassian please comment on what your plans are for this? The last entry from one of you was over a year ago.

Hi Geert,

Sweet plugin! Is it possible for other plugins to hook in to it? For example, if we could make our Theme Builder plugin somehow link to your plugin, we could embed the links in to the theme design for consistency with existing theme layouts...

(gfraser at adaptavist dot com)

I am developing a plugin that may solve some PDF exporting issues: http://confluence.atlassian.com/display/CONFEXT/Outline+Plugin
Take a look and let me know what you think.

Cheers,
Geert

If the PDF export could be customised with a theme plugin, that would be a dream. We've got lots of customers asking if our Theme Builder plugin can customise PDFs but it seems customisation is only possible via editing velocity templates on disk and not via customisations in a theme plugin.

When reading the atlassian blog, I get the impression, that very much companies use confluence for documentation generation.

We use it for this purpose, too.

But the way the PDF Export is implemented makes Documentation Generation a really expensive thing.

If our customer wants that his Documentation follows a style guide we have to do the following:

• Export the Space in PDF
• Convert it to a DOC file, using an Exporter, who converts about 200 pages an hour. WIth the average size of our concepts, this is often a 45 minutes wait.
• Then a student takes the DOC and copy-pastes the whole content into the document template.

Having no Control over PDF Export is an expensive liability.

When I bought Confluence I was under the impression, that the PDF Export would export the pages in the theme of the space.

It would be really great to get a solution on this one.

Hi,

Just a simple one, how to change the font to Arial? I changed the xhtml2fo file, but to no avail...

Thanks

One of the most basic points is that the PC's screen is landscape oriented and the PDF export is by default portrait oriented. You can define that in /confluence/importexport/common_fop.vm (switch height and width), but this has an impact on every page of the site exported to PDF.
What about a PDF bulider (a little like the Feed builder) to configure some settings before exporting:

• orientation (landscape/portrait)
• page format (A4, ...)
• scale content to pageformat (yes/no)
• page sorting (alphabetically, by date, by page number * )

page number *: sure, a hypertext document is not a book, it is not linear. But if you want hold a book like structure, you can (next page, last page, index). And some order criteria like a page number could solve that problem.

Milt Taylor wrote:
> This issue [..] are the major things missing from this product in order for us to jump ship

Hey Atlassian, with other words, this feature will be paid at least partially since you gain a new customer

Milt, there is a

(table of content) macro (at least as a plugin) available plus another which lists a child-document-tree. So TOC should not be a problem.

Am currently looking into Confluence ... using another wiki right now. This issue, plus control of page ordering, printed table of contents are the major things missing from this product in order for us to jump ship. (Not that our current wiki can do this, but I don't have a good enough reason to change yet,).

I would like to see more control on the PDF and Word exports to manage the look-and-feel and to add tags that show all content is draft version only. In the end, when a page is validated for operations, we would like to be ale to promote it and have the print version show the promotion using tags or backgrounds.

PDF export limitations is for also a big issue for us: beign able to control styles used per space, adding manual page breaks, controling the order of child page exporting.

Thanks for letting us know. Please file this as a separate issue and if you can give us any more information, add it to the ticket. Are all PDF exports not working in Illustrator or only specific pages?

Fyi, in case you haven't already heard this: sometimes I open PDFS in Illustrator. Confluence-generated ones give this error: "Acrobat PDF File Format is having difficulties. Could not create internal representation of XMP metadata"

The ability to apply one or more templates to PDFs (generated from spaces, pages, and sub-units) would be very, very useful.

I'm voting for this, but I would like first to express appreciation for how nice the default PDF appearance is. Good going, Atlassian!

The only reason I want better control is that I am thinking of using Confluence in a commercial application as an editor for multiple, fairly naive users, who need nice pdf output and version control/simultaneous editor control. This is replacing a process in which they used Microsoft Word, so they want control over fonts.

It would be useful if we could get control over the stylesheet used for PDF exporting so that heavily customised themes can include their stylesheet to help the PDF more closely reflect what's seen on-screen. As there are relatively few items (pages and news as far as I am aware) that have a PDF export, would it be possible to have 2 dedicated layouts that could be altered to customise the PDF exporting? Possibly some additional layouts for pages such as a contents page, etc?

For my purposes, PDF exporting is essentially broken and useless as it is right now, so a change in the PDF creation process is necessary anyway for it to be useful to me. I now export by printing individual pages to a PDF printer rather than using Confluence's built-in mechanism. Not fun for large documents however.

Thanks for the link. Looks definitely promising.

However, we will need to spend a little more time to investigate whether it is worth to change the PDF creation process completely. I assume also prince will have some problems with complex html content. But it might be an interesting solution for the future.

Here's an interesting article that may be of use for any future development on the PDF export - using CSS3 and Prince, you can get quite good control over PDF output. If a small number of "pagination" macros (or similar) were added to insert things like page breaks (which would only be used on printing or PDF export), contnet authors could gain quite a lot of control over the way the PDF export appears.

The URL: http://www.alistapart.com/articles/boom

Our users often want to be able to change the order of pages in which they appear in the PDF space export. In general, having pages ordered inside a space seems like a good idea useful for many purposes.

Ability to edit headers and footers would get you more fans with the government sector as well. Documents can't be distributed without marking what their distribution rules are, many times.

Personally, I think that PDF, HTML and XML export should be completely separated. XML export is more like a backup process, whereas PDF (and to a lesser extent HTML) export is more of a publishing process. I'm not even sure where HTML export is actually useful...

And yes, it would be nice to have a lot more options in regard to PDF export, mostly those issues listed above, but for me, in particular font size and page order. And they are options which don't make any sense when applied to HTML or XML exports...

Users should also be able to choose the "paper size" for the exports - european users most likely would like A4 size exports while US users want Letter. If the size is constant, printing the exports isn't very nice for one of your big audiences.

Love the page-break idea!

Scott named quite a few enhancements to PDF generation I'd like to see as well.

While I do understand, that Confluence is not a word processor or CMS, I am sure that I am not the only one who wants to get the stuff out of confluence in a nicely formatted and distributable way.
As mentioned before current state of PDF output does not allow the use of Confluence as a production tool for documentation delivery.
In addition to the formatting deficiencies, the most annoying issue is the inability to control the order of pages in output.

While I'm on it I have two more wishes to express

1) allow for intentional page breaks in output through WIKI markup e.g.

which is shown as a dotted line or something
2) give us some flag to mark pages 'production ready' e.g. like 'final' or 'lock' and the ability to generate PDF on that criteria

Again, I think confluence is a great tool but it lacks just a few things to help people get their job done. And don't tell me confluence is just a WIKI. It's not.

improved pdf generation

I couldn't reproduce the code elements not wrapping on 1.4.1, so that seems fixed. (although a long string with no whitespace will fail to wrap)

I'm attaching a modified xhtml2fo.xsl which makes text a more sensible size, and left-justifies text.

There is no quick fix to resolve that problem. The template file only generates the frame for the pdf content. The actual parsing and tag creation is done deep inside Confluence. We will have a look at it, but can't promise that it will make it into 1.5.

Cheers,
Jens

I wanted to mention a little bit of the reasoning behind what I wrote in my bug. We frequently use Conf to generate docs and specs for partners and contractors we work with. Conf is about 95% there on its PDF export. Just a little further and it will make a great spec generating tool.

Is there a quick fix for reducing all the font sizes to an acceptable level? Sure, it works with site-css.vm but with the cost of an ugly screen layout. When I fiddle with xhtml2fo.xsl, there's not much impact on the font size. And up to my humble knowledge of velocity, I can't change the font size of the body in Page.pdfexport.vm.

Any other ideas around?
Marc