Summary: | ERROR -15 closing pdfwrite device | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Mike <mlungu777> |
Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Customer: | 631 | Word Size: | --- |
Attachments: | patch |
Description
Mike
2010-08-17 16:31:10 UTC
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. |