Skip to content

Fix bug: dont remove parent just because children is empty #243

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

kpldvnpne
Copy link

Reason:

Currently there is a bug with PdfOutline.removeOutline function. Here is what happens in this bug:

If there is an outline like this:

Parent Outline
|- Child Outline

and, we remove Child Outline, then the parent outline automatically gets removed because the parent now has no children.

This is the relevant part of the code:

if (children.size() > 0) {
    parentContent.put(PdfName.First, children.get(0).content);
    parentContent.put(PdfName.Last, children.get(children.size() - 1).content);
} else {
    parent.removeOutline();
    return;
}

Hence, in this PR, I removed the line parent.removeOutline(); so that the parent does not get removed.

@vitali-pr
Copy link
Contributor

Hi @kpldvnpne ,
Thanks for your contribution.
Would you mind signing the Contributor License Agreement and send back to us? The details are available at https://itextpdf.com/en/how-buy/legal/itext-contributor-license-agreement - it's required in order to merge the PR.

The change looks correct. What we miss here is still removing top level outline dictionary when its last child is removed.

I also see 2 other related problems:

  • We don't maintain Count value while removing the outline.
  • Removing page issue. I see that PDF processors understand the case when outline destination points to a page using page index. However, according to the spec it should be an indirect reference to a page object. If we want to support 'page index' case properly, we also need to update destinations to refer updated page numbers (page indexes, starting from 0) on page removal.

2 last problems are here for us to solve while further working on your PR. But if you can contribute here, it would be great and will speed up the merging process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants