Fix bug: dont remove parent just because children is empty

[kpldvnpne]

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]

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.

[introfog]

Hi @kpldvnpne
Thanks a lot for your contribution! Your changes have been merged in commit 9b960cb.
Here you could find additional changes we made for your initial idea: fe9ca06. We've added tests and updated Count field.