2

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

MWE:

\documentclass{article}
\usepackage{hyperref}

\begin{document}
\begin{Form}
X \TextField[hidden=true, name=Magic,readonly=true,value=QuickBrownFox]{\phantom{Magic number}} X
\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.

PPS. I am now downloading TL 2020 to see if I can reproduce the old behavior.

Stefan

1
  • 1
    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

1 Answer 1

3

With Ulrike's comment the solution was easy to find:

\usepackage[unicode=false]{hyperref}

did the trick.

3
  • This is true but it would be interesting to know your use case? the unicode option is more or less a legacy code and things would be considerably simpler internally if hyperref didn't have to support the old 8bit pdfencoding. It should be the case that all PDF tools can handle either encoding (and of course Unicode can show a much greater set of characters). The encoding used for PDF strings ought to be an "implementation detail". Jun 21, 2021 at 18:28
  • Sure! As mentioned above I have written a tool in Go using the library github.com/pdfcpu/pdfcpu. It has no built-in functions to export form entries. There is an improvement suggestion in the issue-tracker, though: github.com/pdfcpu/pdfcpu/issues/124. This issue has a proof of concept by 'raff' how to access the keys and values of the form entries programmatically, since I need to process the values in various ways. The hadn't checked at the time if the unicode-versions of the strings can be processed using other functions of the library, because there was no need. Jun 21, 2021 at 20:28
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.