Edit PDF doesn't maintain PDF/A. That isn't its objective, and some would argue that it defaults the whole PDF/A concept. There seems to be some kind of myth that PDF/A is just a "better PDF" and we should be using it as our normal choice.
If you edit a file that happens to be PDF/A, then use preflight to reconvert it. If that is failing, let us know the specific failure messages and we may be able to help with that.
The "A" in PDF/A stands for "Archive", which means that file should not be
edited anymore. If you need an editable file, don't save it as PDF/A but as
a regular PDF.
Thanks for the reply.
I understand the meaning of a PDF/A compliant document.
I want my end document to be archived, so it MUST be PDF/A compliant.
My template is not archived though, and I've built it through acroform fields.
If the template is PDF/A compliant except for the acroform fields, after filling them in the final document would be PDF/A compliant and I can archive it.
Whenever I change the template though (even just modifing font class of a string) I cannot have anymore a template that is PDF/A compliant except for the acroform fields.
This means I have to copy to MS Word the whole document (losing some of the formatting features), make the changes to the Word doc and then copy back to Acrobat the whole document again, that is a quite annoying activity.
Thanks again for any precious support.
I don't quite understand, perhaps we can get closer to the problem with more info.
Your "template" is an acroform, ok.
What process do you plan to take to get rid of the form fields and make it suitable for conversion to PDF/A?
I don't understand your "..after filling them in the final document would be PDF/A compliant".
Briefly, we implemented a custom software that:
1. fills the desired values in the forms
2. flattens the pdf produced
In this scenario, if the template is PDF/A compliant with the only exception of the acroform fields, then the PDF produced is PDF/A compliant.
Thus my only need now is to be able to edit the template without losing the initial condition, that is having it all compliant except for the acroform fields.
Ok, now I understand your workflow better. So now we are back to...let us know the specific failure messages and we may be able to help with that.
Ok, I've made some other tests meanwhile.
Acrobat Version 10.0.0 -> succesfully converted the template to PDF/A and preflight within the same version validates it with no errors
Acrobat Version 10.1.7 ->
if I try to validate with this version of Acrobat the PDF/A produced earlier with version 10.0.0, validation does not succeed.
Preflights returns one error occurring multiple times (in this case: 33), that states: "CIDSet in subset font is incomplete"
I've tried multiple options of fixup in preflight, but no one seems to solve the issue.
open a non PDF/A template, tried to convert it through "save as" -> "more options" -> "PDF/A 1.b", Acrobat creates a PDF which is not PDF/A compliant because of the same validation problems as stated before: "CIDSet in subset font is incomplete".
At the moment I can't figure out how to fix this.
The CIDSet test is a complex area. It may have been added in the later version of Acrobat as a bug fix, as bad PDF/A files were allowed otherwise. It's a strange area, since a bad CIDSet has never stopped Acrobat displaying a file, but the rules of PDF/A don't take that into account.
I have a feeling that Acrobat XI doesn't just detect it but fixes it, but I can't say that for sure.
We are getting closer! Downloaded and installed trial version of Acrobat XI and preflight does fix the bad CIDSet...
Now my last need is to personalize the preflight conversion to avoid losing acrofields. Suggestions?
Since form fields are in effect banned from PDF/A it isn't clear that you could adapt PDF/A conversion in this way.
Actually, "banned" is a bit strong, the real situation is very complex...