When processing a PDF file containing an xref-stream (PDF1.5+ stream 
object replacing the "classic" trailer dictionary and xref table) with a 
pdfwrite.ps-based tool, one gets an "Error: /undefined in --get--". The 
output file is truncated near the end. The xref and part of the trailer 
are present in the output PDF; the last token written is "/File".

Cause:

In this case the trailer is a PDF stream, but it is considered a 
PDF dictionary after being improperly manipulated. The error comes from 
an attemp to write a PostScript file object, operation for which there's 
no entry in pdfwrite.ps::/pdfwritetypes (and there's no need for one).

Sample command lines (Windows version):

    gswin32c -q -dNOPAUSE                                             \
        -c "/runlibfile {//runlibfile exec 3 .setlanguagelevel} def"  \
        -- toolbin\pdfinflt.ps PDFReference16.pdf out.pdf >out.txt
or
    gswin32c -q -dNODISPLAY -dSAFER -dDELAYSAFER                      \
        -c "/runlibfile {//runlibfile exec 3 .setlanguagelevel} def"  \
        -- lib\pdfopt.ps PDFReference16.pdf out.pdf

- "PDFReference16.pdf" is the published PDF Reference Manual, 5th edition.
- Although the symptom is similar to bug #688149 "Problems, including one 
  security-related, with handling dictionaries", it is completely 
  unrelated to that one.
- The "-c /runlibfile ..." is a workaroud for a separate bug which would 
  otherwise raise an error long before the current one; see bug #688151 
  "PDF interpreter needs languagelevel 3, not 2" for details.
- For the pdfinflt.ps test redirect the output to a file, because the 
  o-stack dump is huge (don't know why).
- pdfopt.ps does not write directly to the output PDF. To see what 
  happens, temporarily change pdfwrite.ps::/pdfwritetrailer to dump its 
  parameter before, and print a message after, the "pdfwritevalue" call.