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?

grahan01, users are encouraged to vote and comment on issues that are important to them. An issue that is getting more attention from users is more likely to get picked up or investigated, but I cannot guarantee when the issue might be picked up.

Any number of factors could affect the complexity of an issue. Without investigating the cause, it's difficult to know whether an issue can be easily fixed, or whether it will require significant effort.

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.