Follow-up Comment #15, bug #58206 (project groff):
I misread the output--the problem file from the original submission indeed
contains UTF-16LE, not surprising at all given all the Windows systems in the
world.
And for those who were wondering, I've worked out a tempfile-free way to
manipulate the within-build-tree gnu.eps file into an afflicted gnu.pdf that
reproduces this problem.
So I can get my regression test now.
$ gs -o - -sDEVICE=pdfwrite -f build/gnu.eps -c "[ /Title
(\000B\000U\000S\000T\000E\000D) /DOCINFO pdfmark" | pdfinfo - | xxd | head
00000000: 5469 746c 653a 2020 2020 2020 2020 2020 Title:
00000010: 0042 0055 0053 0054 0045 0044 0a43 7265 .B.U.S.T.E.D.Cre
00000020: 6174 6f72 3a20 2020 2020 2020 2070 6e6d ator: pnm
00000030: 746f 7073 0a50 726f 6475 6365 723a 2020 tops.Producer:
00000040: 2020 2020 2047 504c 2047 686f 7374 7363 GPL Ghostsc
00000050: 7269 7074 2039 2e32 370a 4372 6561 7469 ript 9.27.Creati
00000060: 6f6e 4461 7465 3a20 2020 4672 6920 4a61 onDate: Fri Ja
00000070: 6e20 3231 2031 393a 3538 3a33 3820 3230 n 21 19:58:38 20
00000080: 3232 2041 4544 540a 4d6f 6444 6174 653a 22 AEDT.ModDate:
00000090: 2020 2020 2020 2020 4672 6920 4a61 6e20 Fri Jan
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?58206>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
