Legacy PDF name tokens

THPDFNameObject.Value and legacy dictionary keys retain PDF name tokens without the leading slash; loaded parser tokens can already contain #HH escapes

The legacy writer decodes an existing token and then encodes all reserved bytes, whitespace, control bytes and non-ASCII UTF-8 bytes; existing escapes are canonicalised without double escaping

For example, the token #41 denotes A, whilst #2341 denotes the literal text #41; encode newly authored raw bytes with _PDFNameEncode before storing a literal hash followed by two hexadecimal digits

Invalid hex sequences such as #GZ and a trailing hash remain literal data and are escaped as #23GZ and #23 during serialisation

Leading and trailing spaces are preserved as #20, and the empty name remains an empty PDF name; values in arrays, nested dictionaries and dictionary keys use the same serialisation rules

Names are not PDF text strings: the writer preserves bytes and does not transcode a caller's source encoding; use UTF8Encode when supplying newly authored Unicode names

Fresh native XFA builder dictionaries use decoded keys whilst name values remain token based; adapters must encode those decoded keys once when moving them into the legacy object model