title: Ghostscript won't generate PDF/A with UTF16BE text string detected in DOCINFO - in spite of PDFACompatibilityPolicy saying otherwise
body: <p>I am trying to convert normal PDF files to PDF/A with this command line:</p>
  
  <pre><code>gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=output.pdf input.pdf
  </code></pre>
  
  <p>However, I get the message</p>
  
  <pre><code>GPL Ghostscript 9.26: UTF16BE text string detected in DOCINFO cannot be represented in XMP for PDF/A1, reverting to normal PDF output
  </code></pre>
  
  <p>an gs reverts to normal PDF.
  Apparently, the message stems from <a href="https://ghostscript.com/pipermail/gs-cvs.mbox/2018-June/022891.html" rel="nofollow noreferrer">this code fragment</a> of gs, but there we read that the message can occur only when <code>pdev-&gt;PDFACompatibilityPolicy == 0</code>. My understanding was that the parameter <code>-sPDFACompatibilityPolicy=1</code> in the command line has the purpose of preventing this.</p>
  
  <p><strong>Q:</strong> Why does gs behave as if the desired policy were 0 instead of 1? Is there another way to set the policy to 1?</p>
  
  <p>Also, just as it makes me curious:</p>
  
  <p><strong>Q:</strong> Is there a way to see what kind of strange DOCINFO there is causing the original problem or to prevent it in the first place? Using Acrobat Reader, I cannot see anything "suspicuous" in the file. If it helps: The input.pdf is generated on Window from Word (and I tried even with the UseISO19005-1 setting, which should produce PDF/A to begin with, but the problem occurs anyway). </p>