PDF/A is supposed to be a final format, so late edits are not expected and it's designed to be invalidated (though this isn't always the case_. But generally it can be beaten back into PDF/A if you haven't broken it or added bad things.
What are the specifics of the preflight report after adding the JPEG?
what you say about PDF/A being a final version makes a lot of sense, but not when you are talking about digital signatures of course.
if you first sign and then convert the file to be PDF/A compliant you automatically invalidate the signatures.
long term electronic archiving and digital signatures is a perfect match, and people still ike to see their hand written signature, even on an electronic document, and it is exactly where the problem begins.
the pre flight is very cheap with information.
it gives me a general note on the XObject that it should start with stream and then CR LF, and must end with an endstream preceeded by EOL. as far as I can tell my object complies with these requirements
I would start with the assumption that the preflight report is correct until there has been independent verification at least. Are you able to share a sample file on a public site?
Acrobat most certainly maintains PDF/A compliance when signing - we worked very hard to ensure that is the case. Of course, that assumes that the "appearance" for your signature doesn't use any PDF/A-incompatible elements. JPEG, for example, is quite fine - provided that the colorspace of the image matches the OutputIntent of the PDF. (eg. an RGB JPEG would invalidate a CMYK PDF/A).
As to the error in question - it seems pretty explicity as to the reason your particular image is failing. I would check with a hex editor on the PDF in question.
here are 2 samples. not the original files, as they are under NDA, but I hope that they are good enough.
the JPG file is the one with the error, the BMP looks fine.
I opened the file with an hex editor - stream is followed by an 0x0a, and endstreem is preceded by 2 of those.
If endstream is preceded by two 0x0a, we don't even need to look at the file, that clearly isn't what the message says is allowed...
I confirm that what you described is indeed the problem.
I removed one LF (actually moved it after the endstream, so I changed no offsets), and it seems as the problem was solved (the signature became invalid of course, but as I changed the file it was expected).
Thanks so much for all the prompt replies
The PDF/A spec is a dull document, but it is a precise one. You may not have a copy (though if you are doing the job of editing PDF/A it could be a good investment) but, conveniently, the preflight message quotes the spec exactly.
So, when the spec says ...keyword endstream preceded by an EOL marker... we have to understand that the "an" is a singular, and so the only possibility is exactly one.
I have no idea why the authors of PDF/A felt that they needed to add these extra rules to PDF, but there it is. Committees make strange decisions sometimes.