Conversion of files to PDF/A

Question

I have been spending a lot of time lately trying to ensure that an important document can be 'archived', i.e. opened at a later date looking exactly as it should, without relying on external files (e.g. fonts) not embedded in the PDF.  Essentially this means making the PDF PDF/A compliant (specifically PDF/A1b is sufficient for me).  I created the original file (not PDF/A-compliant) for printing with Acrobat 7 Pro (v7.1.0).
There were two problems here:
* the PDF/A standard had only been drafted when Acrobat 7 was released;
* all my efforts to recreate a visually-identical PDF file (PDF/A-compliant) using Acrobat 9 Pro (v9.1.0) from the original source files (MS Word) failed.  There were always visual differences.  E.g. http://forums.adobe.com/message/1931760#426522.
The next option, therefore, was to convert the general PDF to a PDF/A-compliant format. This means flagging it as PDF/A-compliant, embedding fonts, etc.  Critically, it also requires a character-ID to glyph-ID map (CIDtoGIDMap).
I had previously trialled the pdfaPilot plugin (from Callas Software) from within Acrobat 7 Pro, and this also couldn't quite manage.  Nevertheless, it did a better job than the Preflight conversion using Acrobat 9 Pro on it's own, which couldn't seem to fix the CIDtoGIDMap problem(s).
I have just attempted a conversion on the same stubborn file with pdfaPilotServer (standalone application from Callas Software), and this seems to have done the job of making the file PDF/A-compliant (for archiving).
—DIV

Answer 1

In a post above I complained that Callas' pdfaPilot Server did not (by default) set the output intent as sRGB. This seems to have been a case-specific problem, where the sRGB output intent was not specified in the original (non-PDF/A-compliant) PDF.  Although colours were used in the document, pdfaPilot Server opted to set the parameter "Color space of data" as "GRAY", instead of "RGB ".  Having said this, I should point out that this had no apparent ill-effect on the display of the now PDF/A-compliant document.
Nevertheless, the PDF/A-compliant status was lost by inserting an explicitly-tagged RGB object into the PDF document, namely a 'Sticky Note' comment using Adobe Acrobat.  Running pdfaPilot Server over the modified file restored PDF/A-compliant status, and now recognised "Color space of data" as "RGB ".
Alternatively, I could have avoided the need to convert twice by overriding the default settings using a command "--outputintent="<path to sRGB Output Intent file>"".
A key point is that Adobe Acrobat 9 Professional (v9.1.0) was in each case either (i) unable to achieve PDF/A-compliance or (ii) achieved compliance, but in the process altered the appearance of the document (including placement of black text).
While pdfaPilot can be improved in some areas, such as perhaps the colour detection, I especially commend Callas Software for their prompt and helpful attention to technical enquiries.
—DIV