Well, you may simply convert MS Excel file to PDF via Aspose.Cells APIs and then use Aspose.PDF API to convert the output PDF (by Aspose.Cells) to render WCAG compliance PDF. Similarly you may try to use Aspose.Slides to render Powerpoint presentation to PDF and then use Aspose.PDF API to convert the output PDF (by Aspose.Slides API) to render to WCAG compliance PDF.
Anyways, for your requirements, we have also logged your feature requests for both APIs into our database. Following are the tickets logged for your demanded feature:
CELLSNET-46642 (Aspose.Cells)
SLIDESNET-40996 (Aspose.Slides)
Once we have an update on any of the tickets, we will let you know.
Currently Aspose.Slides and Aspose.Cells do not provide this feature while converting to PDF. That is why we have logged new feature requests under these two tickets for the respective products. When these tickets will be resolved, this feature will be directly available using each of the product.
Sorry I’m need a bit of clarification about, CELLSNET-46642 (Aspose.Cells) and SLIDESNET-40996 (Aspose.Slides) to prevent any issues down the line, and if necessary assurances regarding the different Compliance formats available.
We are working to comply with The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 which comes in to force 23rd September 2019; so my first question is will these fixes be ready well in advance of this date (so that we can confidence test them, and roll new version out to customers)?
My second question is then about the various compliance options on the Pdf Export options across the product. Each product (Words, Slides, Sheets) offers a compliance option which are normally Pdf15, PdfA1a, PdfA1b (However slides does not even offer PdfA1a). Based on my research PdfA1a is best; but it has short comings (such as a lack of transparency) that will cause problems for our customers. PdfA-2 and better PdfA-3, but don’t seem to be available as part of your product. Is this something that will be implemented, or are you planning on adding a Pdf/UA option that ensures compliance with ISO-14289? If there is no need to implement these in your product to meet accessibility standards please can I have a statement of confidence that your product meets the accessibility standards that I can take to my boss?
For your above question from reference of Aspose.Cells we can not share ETA at this moment but supported version might be available in the fourth quarter of 2019. From Reference of Aspose.Slides ETA is not earlier than 2019’Q2.
We have plan to implement this feature and will inform you once this feature implemented in Aspose.Slides.
Thank you for confirming you will be adding PdfA1a to Aspose.Slides.
The question about compliance types goes deeper than that though. I’ll try and explain with an example:
If I use Aspose.Words to make a word document and want to convert it to a pdf using Aspose.Words.Document.Save() I can set it to create a structured document with
opts.ExportDocumentStructure = true; But then the Pdf itself should also be a suitable format to be accessible.
It is therefore my understanding that I need to set opts.Compliance to a suitable value. The available options only being Pdf15, PdfA1a, PdfA1b. And while PdfA1a is technically accessible it has shortcomings, with the expected standard being Pdf/AU. Therefore I am asking for either:
A statement explaining that I have misunderstood the relationships of the different compliance levels to Accessibility.
A statement from you confirming that PdfA1a is suitable to meet the compliance needs of ISO-14289, the WCAG standards and associated EU/UK legislation.
Details confirming that there is going to be a Pdf/UA option available for the compliance and when this will be available in your software.
A method in the existing product by which I can take a word document and convert it to a PDF/UA (ISO-14289) compliant pdf.
I appreciate we are getting in depth on this matter but I have to demonstrate that in using Aspose I can meet the legislate requirement, so your help is very very much appreciated.
I believe I can offer some more information to assist you in scoping our requirements.
The WCAG 2.1 standards for pdfs can be found here: PDF Techniques | Techniques for WCAG 2.0 (Please note while these are the WCAG 2.0 they are not changed for WCAG 2.1).
The bulk of these are controlled by the document author so the only requirement regarding your product is that when converting to pdf is that any accessibility structure they have added is not lost or altered on conversion.
However; there are also the following requirements I believe we will directly need to do programatically, I have broken them down by product:
Aspose Words/Aspose.Slides/Aspose.Sheets
Export of document structure
The creation of bookmarks from syntactic headings (document outline)
The preservation of a document’s language flag (/LANG in the pdf)
The ability to optionally set a document’s language flag.
The ability to specify the pdf document’s title.
Aspose Pdf
Ability to specify the document language on a pdf (/LANG)
Ability to specify the title of a pdf file (/TITLE)
Ability to mark specific Aspose.Pdf.Stamps as ‘Artifacts’
We are combining multiple pdf documents via Aspose.Pdf.Facades.PdfFileEditor.Concatenate so it is important that no accessibility elements are lost in this process.
I am happy, within reason, to carry out a small amount of post processing of our concatenated document regarding elements such as /LANG and /TITLE.
Document format
The discussed pdf 1.5, pdfa1a, and pdf1b are all quite old formats, each superseded by new versions so ideally we would benefit from being able to convert to a new compliance format from each of the office formats (ideally this would be Pdf/UA); however, if you can provide confidence that accessible documents created in the various office suites maintain WCAG 2.1 compliance when converted to pdf1.5 then I may be able to continue to use Pdf1.5 in the near future.
Conclusion
I appreciate that some of the products can already do the required actions and in these cases please can you advise on the setting I require. I am already aware of the Words.PdfOptions.ExportDocumentStructure so that one does not require addressing and I understand that this is to be added to Sheets and Slides, but for any others I would appreciate guidance.
I have observed the requirements shared by you and have created an investigation ticket with ID SLIDESNET-41023 in our issue tracking system to investigate whether it is possible to meet the illustrated requirements using Aspose.Slides or not. I will share the feedback with you in this regard as soon as possible.
Please try our latest version/fix: Aspose.Cells for .NET v19.3.2 (attached)
In the fix v19.3.2, we now support to save to tagged PDF using the new API: PdfSaveOptions.ExportDocumentStructure .
e.g Sample code:
Workbook wb = new Workbook(srcFile);
PdfSaveOptions saveOptions = new PdfSaveOptions();
saveOptions.ExportDocumentStructure = true;
wb.Save(outFile.pdf, saveOptions);
Please note, currently, we only support to create tagged PDF as what Aspose.Words API does. It may not be WCAG 2.0 compliant. The ticket is still Open and we will continue to look into it.
Is there an update on the progress with the outstanding requests on this case please? As we are drawing closer to the deadline and I need to provide an update on this.
I am afraid, we cannot fix the issues related to Aspose.Slides API soon. We are very sorry but due to more priority issues (on hand), the tentative ETA for these issues is 2020’Q1.
In reference to SLIDESNET-40996; I have upgraded to Aspose Slides 20.8 via Nuget. Please can you advise me what property I need to set to enable ExportDocumentStructure?
Thank you, I’ve checked the Aspose.Slides.Export.PdfCompliance enum and I only have ‘PdfUa’, I assume this is what you are referring to, but please can you clarify?
While this solution is fine if it exports the document structure, I was suprised as both Aspose.Words and Aspose.Sheets have an property ‘bool ExportDocumentStructure’ on their Options class so I had assumed it would be consistent; but as I say, if it does the job then that is fine.
Yes, you are right as it was a typographical error. Please check this link for your kind reference.
Secondly, you are right. We try to maintain as much uniformity as possible in our APIs for easy utility but sometimes things are implemented differently inside and hence have different ways to use.
The issues you have found earlier (filed as CELLSNET-46642) have been fixed in this update. This message was posted using Bugs notification tool by simon.zhao