We are currently testing PDF conversion using Aspose.Words version 22.5.0.0 and have encountered an issue related to color preservation in the output PDF.
Issue Description:
When converting documents to PDF with the following compliance setting:
opt.Compliance = PdfCompliance.PdfUa1;
the colors are missing in the output PDF.
When we comment out the compliance setting, the conversion preserves colors as expected.
Can you please review the Input and output files and let us know in case need more details.
Summary
When PdfSaveOptions.Compliance is set to PdfCompliance.PdfUa1, Aspose.Words removes the background colour of form fields to meet the PDF/UA‑1 accessibility requirements. As a result, the generated PDF does not show the colours that are present in the original DOCX.
Why it happens
PDF/UA‑1 rule – The specification requires interactive form fields to have a transparent background so assistive technologies can read the content reliably.
Aspose.Words behaviour – Enabling the PDF/UA compliance flag makes the library automatically strip any fill colour from form fields (TextFormField, CheckBox, ComboBox, etc.) to produce a PDF that can pass PDF/UA validation.
Not a conversion bug – Saving the same document without the compliance flag retains the colours, confirming that the colour loss is an intentional accessibility‑compliance step.
What to do next
Determine whether PDF/UA compliance is required If a fully accessible PDF is needed, the colour removal is expected and cannot be overridden in the current Aspose.Words API.
If PDF/UA compliance is not required – omit the compliance setting (or use another compliance level such as PDF/A). The colours will be preserved.
var doc = new Document("InputDocument.docx");
var saveOpts = new PdfSaveOptions(); // No compliance flag
// Optionally: saveOpts.Compliance = PdfCompliance.PdfA1b; // for PDF/A
doc.Save("Output.pdf", saveOpts);
If PDF/UA compliance is required and you need coloured form fields – add the colours after the PDF is generated, using Aspose.PDF (or another PDF library).
// 1. Create a PDF/UA‑compliant file (colours will be stripped)
var doc = new Document("InputDocument.docx");
var uaOpts = new PdfSaveOptions { Compliance = PdfCompliance.PdfUa1 };
doc.Save("Temp_UA.pdf", uaOpts);
// 2. Re‑open with Aspose.PDF and set background colours manually
var pdfDoc = new Aspose.Pdf.Document("Temp_UA.pdf");
foreach (var field in pdfDoc.Form.Fields)
{
// Example for a text box field
if (field is Aspose.Pdf.Forms.TextBoxField txt)
{
txt.BackgroundColor = Aspose.Pdf.Color.FromRgb(255, 255, 200); // light yellow
}
}
pdfDoc.Save("Output_With_Colors.pdf");
Validate the final PDF – run a PDF/UA validator (e.g., a free PDF/UA checker) to confirm that the document still complies with the accessibility requirements after any post‑processing.
Version note – According to the Aspose.Words documentation up to version 22.5, there is no API that preserves form‑field background colours while PdfCompliance.PdfUa1 is active. The post‑processing approach described in step 3 is the recommended workaround.
If you need additional guidance on handling specific field types or preserving other visual attributes, feel free to request further code examples.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.
@pjumbad Editable forms are prohibited by PDF/A compliance. So even if PdfSaveOptions.PreserveFormFields property is set to true, false value will be used automatically when saving to PDF/A.
Form fields are not supported when saving to PDF/UA.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.