I'm converting PostScript / PDF files into PDF with GhostScript - the command line i'm using is: gswin32c -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=out.pdf -f in.ps docinfo.ps where docinfo.ps is: [ /Title (\376\377\116\241\127\013\166\204\200\241\160\175\000\055\000\055\170\070\145\267\131\047\156\005\127\013\201\010\166\204\166\333\131\017\135\051\166\344) /DOCINFO pdfmark if -dCompatibilityLevel=1.4 or -dCompatibilityLevel=1.5 i get an "ERROR -15 closing pdfwrite device" for any postscript/pdf file i try to convert. If -dCompatibilityLevel=1.3 or -dCompatibilityLevel=1.2 it works just fine.
Created attachment 6667 [details] patch Fix incorrect (and inconsistent) advance of the character index after decoding escape sequences in the PS string. Now decode_escape() always advances to the full length of the sequence. For instance, 4 for \123 .
This issue exposes three separate bugs in the processing of Unicode strings and XMP metadata. Firstly as Alex says in comment #1, the character index counting was wrong when converting PostScript escaped strings into binary, the character was advanced past the last consumed character if it was not an octal escape, and up to the last consumed character for an octal escape. This meant that non-octal escapes consumed an extra character from the buffer. Secondly, the backspace escape (\b) was not recognised, causing return of a 'b' character instead of the binary value 0x08. Thirdly the conversion from UTF-16 into UTF-8 used the wrong value for the end of the destination (UTF-8) buffer, causing an invalid abort because of buffer overflow. I have fixes for all 3 of these, and am about to regression test them. I also want to check and see if there are any other PostScript escape sequences not being catered for.
Fixed in revision 11649, patch here: http://ghostscript.com/pipermail/gs-cvs/2010-August/011663.html
Changing customer bugs that have been resolved more than a year ago to closed.