When manufacturing PDF/A output files we need to create XMP metadata. If the metadata strings are UTF-16BE encoded, *and* a string contained a numeric, then the decode_escape routine fails to correctly decode the octal values resulting in garbage in the XMP metadata or (depending on the memory initialisation) an error.
This was caused by the ridiculous assumption in the decode_escape routine that octal escapes would always be terminated by a non-numeric character, and this condition was used to terminate a loop. In fact escaped octal values should always be three digits (or less!), and this limit is now what is used. The old code consumed numeric values ad infinitum until a non-numeric character was encountered.
Fixed in revision 10785, patch here : http://ghostscript.com/pipermail/gs-cvs/2010-February/010533.html
Changing customer bugs that have been resolved more than a year ago to closed.