Support encoded dest-strings in /GoTo destination dictionaries (issue 14864) #14865
Conversation
… 14864) Interestingly enough this appears to be the very first case of *encoded* dest-strings, in /GoTo destination dictionaries, that we've actually come across. What's really fascinating is that it's less than a week after issue 14847, given that these issues are *somewhat* similar.
|
/botio unittest |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/f9070057af8a8f5/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/51b1e3b1167c318/output.txt |
|
It reminds me this article: https://www.pdfa.org/understanding-utf-8-in-pdf-2-0/ |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/f9070057af8a8f5/output.txt Total script time: 3.53 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/51b1e3b1167c318/output.txt Total script time: 6.62 mins
|
|
Not sure these are encoded right, though (unless there’s another commit between 2.13.216 and master that does this; I just retrofitted this commit on top of the prebuilt release to test this):
|
|
I would expect “H%C3%A4ndel”, for example. (This is unrelated to the other issue, I didn’t know about it, and I had to kick Tₑχ/LᴬTᴇΧ really hard to even generate this (read: I’m doing the UTF-16 encoding outside, in a script).) |
Interestingly enough this appears to be the very first case of encoded dest-strings, in /GoTo destination dictionaries, that we've actually come across. What's really fascinating is that it's less than a week after issue #14847, given that these issues are somewhat similar.