# With pdflatex: How to revert PDF's Text object "T" back to ascii from octal?

I have a fancy PDF document with lots of forms that I created with hyperref.

MWE:

\documentclass{article}
\usepackage{hyperref}

\begin{document}
\begin{Form}
\end{Form}
\end{document}


My users fill out the PDF and I use a handwritten tool to extract their answers.

Since yesterday (and after updating to TexLive 2021), pdflatex is creating garbled PDF texts from my unchanged TeX-files. When I try to extract keys and values from the filled-in PDF, I find that the strings are suddenly encoded with interspersed octal codes:

A line from the newly created PDF might look like this:

/Subtype/Widget/F 6/T(\376\377\000M\000a\000g\000i\000c)/FT/Tx etc.


One can see the word magic interleaved. But this is how it looks in my older files:

/Subtype/Widget/F 6/T(Magic)/FT/Tx etc.


How can I tweak pdflatex to revert the behavior to create ASCII strings?

What is the meaning of the 376, 377 and in particular 000 char codes?

Any hints appreciated. Do I need to write an octal decoder? What to do with those codes?

PS. I have consulted the PDF reference third edition, but I am not finding it helpful.

Stefan

• hyperref uses now the unicode option by default for all engines, you would have got the same in older version is you had use \usepackage[unicode]{hyperref}, or if you had used chars out of pdfdocencoding. The code is a valid encoding in pdf. Jun 21, 2021 at 18:02

\usepackage[unicode=false]{hyperref}

• The Unicode is pretty trivial to decode I'm sure go can handle the octal then ignore the leading \376\377 which is the byte order mark then the rest is UTF-16 which means that in the range that you could handle with the legacy pdf encoding every other byte will be 0 (\000) so you should be able to do it in a line or two of go (although actually I don't really know go) but it would be a line or two of python or Lua or C or .... Jun 21, 2021 at 20:34