May I suggest you upgrade from iText 2.x to OpenPDF:  https://github.com/LibrePDF/OpenPDF

Dang. No more votes. At least, not yet.

I don't like to admit it, but perhaps I'm flogging a dead horse. However much I want this bug to be fixed, if I were Atlassian, I'd be thinking, "34 votes since 2011? Not a high priority".

Out of curiosity, I searched jira.atlassian.com for issues that are unassigned and unresolved, and have more than 34 votes.

My search string, in case I got it wrong:

According to that search, there are 2720 such issues.

Further restricting the search to project = "JIRA Server (including JIRA Core)" returns 557 issues.

Perhaps I need to revisit exporting HTML instead of PDF.

I've just created the discussion item "Got links to anchors? Want them to work in exported PDFs?" on the Atlassian Community website, encouraging people to vote for this issue.

Watchers, please feel free to spread the word.

Let's see if we can, after all these years, raise the "score" of this issue high enough to get Atlassian to fix it.

Overheard in a corner of my mind :

Imaginary person 1: How would you describe X's responsiveness to bug reports?
Imaginary person 2: Glacial.
Imaginary person 1: That bad, huh?
Imaginary person 2: Actually, no. Worse than glacial. Atlassian.

Atlassian,

Suppose a Confluence user inserts a link in one page to an anchor in another page. Then they export both pages to a PDF. I think it's reasonable for the user to expect that link to work in the PDF.

Do you agree?

If you do, then—especially since you've left this problem unfixed since 2011, and show no inclination to fix it—you could at least describe the current behavior (as a "restriction", or however you choose to characterize it) in Confluence documentation topics, such as "Links" and "Anchors", so that users are more likely to be aware of it, rather than—as you and I both agree is reasonable—expecting such links to work in PDFs.

What do you think?

Hi alyakovlev,

Thanks for the information, that's useful.

Regarding your bug fixing policy: what, if anything, can I do to raise the (composite) "score" of this issue, to push it across the line, so that your developers will work on it?

One idea: I could create a new discussion item on the Atlassian Community website, asking users to vote on this issue. Does that sound reasonable?

According to other users, this feature (links to anchors in exported PDFs) used to work in earlier versions of Confluence; based on that premise, the "complexity" score would likely be low. (I realize that statement might be hopelessly naive. Subsequently introduced features might have complicated this fix; perhaps even caused the problem.)

grahan01, thank you for your feedback. The Affects Version field helps us to know what version the bug was introduced in and to gauge whether a bug still exists in newer Confluence versions. However, the issue doesn't fall off the radar if this field isn't updated. As long as there are still comments, votes, and related support requests, the issue continues to appear and continues to be prioritised by the estimated user impact. We do look at individual comments to see if users are still reporting this in newer versions, and then update the Affects Version field.

More info:

https://community.atlassian.com/t5/Jira-articles/Answers-to-your-burning-questions/ba-p/590058

https://confluence.atlassian.com/support/atlassian-bug-fixing-policy-201294573.html

Atlassian (alyakovlev),

Thanks for updating the Affects Version/s field (I notice you've added 6.7.3).

I'm curious: how do you (Atlassian) use that field to decide which issues to work on?

One reason I ask: had this issue "fallen off your radar" because 5.10 was, until now, the most recently cited version affected by this issue?

For issues that are reported for one version, but are not fixed in that version or later versions, and remain unfixed in the current version, what role does Affects Version/s play?

It's worth revisiting the practical impact of this issue with an example.

My employer needed to formalize and expand some of its policies. One reason: we needed to show these policies to an external organization. We decided to document the policies in Confluence (a convenient place for us to develop the policies and make them available to other employees), and export a PDF to show that external organization.

We based the heading structure for these policies on an ISO standard. (We chose an ISO standard because it made sense in this context, not because we were seeking ISO accreditation. I can explain, if asked.) That structure consists of about 160 headings across 3 heading levels. We decided to chunk that heading structure into multiple Confluence pages at the highest heading level. That gave us 14 pages. Yes, we could have chunked the headings at the lowest (third) heading level, and that would have sidestepped this issue, but at the time, we were unaware of this issue.

Some reasons we deliberately chose not to chunk at the lowest heading level (feel free to skip this list; I include it in case Atlassian feels that lower-level chunking is a no-brainer workaround):

• We're not immediately planning to "populate" all 160-or-so headings.
  In the short term, we only need to address a subset of the headings. So some of the headings will remain "empty". However, we want to keep the complete heading structure as a "living gap analysis" of our policy compared to the ISO standard.
• It would have been more work.
  I semi-automated the creation of the markup for the Confluence pages, but created the 14 chunks manually. Given time, I could have automated the creation of those 160 pages, but I needed to get started immediately on the content.
• The Confluence web UI's lack of out-of-the-box support for search'n'replace across pages is a problem for us.
  We don't want to buy additional plugins at this point. I've researched bespoke methods, such as user macros, to do this; but again, I needed to concentrate on the content. Manually editing 14 pages is easier than manually editing 160 pages.
• We wanted to use the Table of Contents macro to display "custom" TOCs based on regex patterns that matched the "tags" we added to some headings.
  (Here, I'm using "tags" in a colloquial sense, not in the specific Confluence sense. We appended certain "telltale" strings in parentheses to some headings.) However, the TOC macro only shows headings in the current page, so we had to create a page that included the entire policy. I created a page with 14 Include macros. That was the best solution I could come up with using "out-of-the-box" macros. (I'm not against developing custom user macros, I just don't have time right now.) For possibly too much information on this, see my question "Table of Contents macro that includes headings from descendant pages?" on the Atlassian Community website.

The external organization had a list of requirements they wanted us to meet. I created a Confluence page that mapped those requirements to our corresponding (mostly third-level) policy headings. The page contained links to anchors (Anchor macros) that I had inserted in the relevant headings in those 14 pages. That page would have been the ideal entry point for that organization: starting from their requirements, with links to our policies.

Those links don't work in the PDF exported from Confluence. That's extremely frustrating.

Atlassian, please update the "Affects Version/s" field of this issue to reflect reality.

Still a problem in 6.7.0.

This issue was created in September 2011. According to the work log of this issue, as of today (May 2018):

No work has yet been logged on this issue.

Confluence support for export to PDF really is moribund . See also CONFSERVER-55407.

issue created 27/Sep/2011 

You guys from Atlassian are so funny  , no wonder i spent almost 20-30% of my Jira usage for debugging, migration and export issues

Also still a problem with 6.6.1.
Please fix this, as it is vital for our documentation process that we can link to relevant portions of a page and make life easier for our customers.

Also still a problem with 6.1.1.

Please fix this, as it is vital for our documentation process that we can link to relevant portions of a page and make life easier for our customers.

This is still a problem in Confluence Server 6.0.2. It would be great to have a resolution on this.

Also looking forward to see this bug fix.

Yeah...for years!

Agree with @James

If this issue has been in the backlog for four years, please either mark it as "Will Not Be Resolved" or do something about it? Cross-referencing content in other sections of a generated PDF document seems like basic behaviour.

@Reto: Yes, your conclusion sums it up nicely.

Unfortunately, the link above doesn't seem to work anymore - page has been deleted.

My conclusion so far is that, even in the most recent version of Confluence, there is no way to create PDF links to anchors which are not on the same page. Am I missing something?

Hi Guys,

As a workaround you have to insert the anchor at the beginning of the paragraph or image following the heading.

I tried the trial version of Scroll pdf and office and faced the same link problem. But found a workaround in

http://www.k15t.com/display/PDF/Creating+Anchors+in+Headers

It worked for default pdf export but in NOT in customized pdf export.

Hope this helps to an extent.

Hi Steffen

thanks for the update. This information is going to a great help.

Regards
Steve Haffenden
Confluence Bugmaster
Atlassian

Hi Steve,

on one of the other duplicate issues I already gave my interpretation of this problem. To make sure the information won't get lost I happily copy it here again:

I also am searching for a solution to this problem. But I doubt that it has to do with the "#".
My reasons:
1) Links to anchors on the SAME page work without problem although they also include a "#"
2) Having a look at the underlying html code there is no difference between a) links to other pages and b) links to anchors on other pages. But the result is that a) works and b) doesn't.
3) When I link to another page (which normally works without a problem) but miss to include this page in my export then I get the same wrong result: Instead of creating a link within the PDF a click on the link causes the web browser to open.

So I think that this specific combination of a link that a) goes to another page and b) has an anchor just can't be resolved properly. Hence the links are not included correctly into the PDF file. And opening the web browser instead seems to me like just some sort of fallback option.

Just my thoughts. If someone knows better don't hesitate to correct me. Anything that gets us closer to a solution is fine with me.

Hi Thomas

Thanks for getting in touch, I appreciate your feedback. The more complete the information that we have on an issue the easier it is for us to identify root cause which can aid us in the resolution of the issue.

With regards to this specific issue. Obviously we want to fix this, although its been open for a decent amount of time we will be addressing this as soon as we can. Unfortunately we do need to ensure that we address these issues in priority order, so for the time being this issue is not on our immediate backlog.

You can read more on our bugfix policy here: https://confluence.atlassian.com/display/Support/Atlassian+Bug+Fixing+Policy

Regards
Steve Haffenden
Confluence Bugmaster
Atlassian.

if it ain't working in an old version and it hasn't been indicated as resolved, it ain't gonna be resolved in newer versions, or do you guys at Atlassian really believe in a deus ex machina or santa claus?
Instead of updating the affected versions, you'd better start fixing the issue or give a decent explanation why this doesn't work since 4.0

Im new to this Confluence (5.2.3) and shocked to see pdf link opeing in a broswer...

This will bad if readers lauching on a invalid web page.

I request this bug to be worked on high priority.

Finally an update:
Too sad that only the list of affected versions was extended ;-(
"Hey, now it also doesn't work in 5.1.1" was not what I was hoping for.

really, how hard can it be? A functionality that was available in 3.5 and now all of a sudden (apparently already since the major 4.0 release) no longer working... i'm already looking for other documentation tools, because the quality of our 5.1.1 version is incredibly LOW and disappointing.

get your things together, you're becoming like Microsoft, they are masters of ditching functions that work and even worse they don't listen to their users.

I support having this issue fixed as well - being able to link to parts of other pages is important for exported documents as well as in-situ. Custom CSS or js files aren't a workaround, they're a means of covering up a blemish.

100% support. This is a very basic function, it used to work in old versions. And still it is not possible to fix it within more than a year.

Please reconsider fixing this issue. We use the PDF export for generating our documentation for customers.