Ensure Matching Encoding Between Name Tree Keys and Go-To References

[zarkogajic]

Hi Support,

This will be a more technical post...

I have a PDF where UTF-16BE with BOM is used to define named destination keys in the `/Dests` name tree, for example:

```pdf
1 0 obj
<<
/Metadata 2 0 R
/Names <<
/Dests 3 0 R
>>
>>

3 0 obj
<<
/Names [
<FEFF006E00640031> [ 4 0 R /XYZ 0 841.889764 null ]
<FEFF006E00640032> [ 6 0 R /XYZ 0 841.889764 null ]
<FEFF006E00640033> [ 7 0 R /XYZ 0 841.889764 null ]
]
>>
```

However, a bookmark referencing the first named destination uses a regular ASCII string for its `/D` entry:

```pdf
9 0 obj
<<
/Next 10 0 R
/A <<
/D (nd1)
/S /GoTo
>>
>>
```

So, although both represent the same textual value (`nd1`), their underlying byte sequences are different.

PDF-XChange Editor has no problem resolving this bookmark: it finds the named destination and displays its properties correctly, despite the different encodings.

ISO 32000-1, Section 7.9.6 (Name Trees), states: "any encoding of the keys may be used as long as it is self-consistent; keys shall be compared for equality on a simple byte-by-byte basis."

PDF-XChange Editor appears to handle this case successfully, even though the byte sequences do not match.

My question / feature request:

When saving the PDF, would you consider normalizing the `/D` entries in Go-To actions so that their encoding matches the corresponding named destination keys in the Name Tree?

In this example, that would mean saving `(nd1)` as a UTF-16BE string with BOM, consistent with the corresponding Name Tree key.

This would ensure consistent encoding and avoid potential compatibility issues with stricter PDF parsers.


-žarko