iText Core/Community 7.2.4

As the last quarter of 2022 rolls around, it’s time for our final release of the year for iText 7 Core. While there’s nothing quite as big to announce as the Android reference implementation from last time, we do have a few cool new things in iText 7.2.4 to tell you about. There’s a nice convenience method improvement for creating tagged PDFs, plus a couple of changes relating to default color spaces for PDF/A documents, and for PDF/A detection in the sign module.

Let’s talk about the changes to PDF tagging first. We noticed that when you apply iText's tagging defaults to somewhat advanced layouts, it could result in rather convoluted tag structures. You could remedy such issues by calling getAccessibilityProperties().setRole(null) on the layout element(s) that don't have semantic value, which attaches all children of the layout element to the element's parent for tagging purposes. However, this was a little inconvenient since invoking setRole(...) is not chainable with regards to the underlying layout element, since it operates on AccessibilityProperties instead of on the layout node itself. This meant that to use this feature, you would need to create an intermediate variable to hold the layout element you wish to be "tag-neutral". To improve things, we’ve added a chainable setNeutralRole() method which can be implemented at the layout element level instead, which is a much more elegant solution.

As for the change to PDF/A default color spaces, ISO 19005-2 6.2.4.3 states that when rendering colors specified in DeviceRGB or DeviceCMYK, and where no matching device independent default color space has been set, conforming readers should use the profile in the file’s PDF/A OutputIntent dictionary as the source color space. Previous versions of iText were not aware when some content was drawn using the color space set by default, and so we’ve now added a check for the Default Color Space in our PdfAChecker mechanism.

In addition, we’ve made an improvement to the sign module relating to the detection and initialization of PDF/A documents. In previous versions of iText 7 Core, we did not check if the given document was a PDF or a PDF/A document. This prevented the PdfSigner from initializing the document as a PdfADocument if it was required. Now the PdfSigner class will check to see if a document claims PDF/A conformance, and treat it accordingly. Note that this does count as a breaking change, so see the example linked below to learn more.

We have also fixed a bug where BBox values for table cells would be inaccurate, leading to text clipping issues. See the example linked below for more information about this fix.

In other news, we have upgraded our Java BouncyCastle dependency from version 1.69 to 1.70.

Improvements

• Updated jackson-databind dependency to 2.13.4
• PDF/A: Add check for Default Color Space
• Implement chainable API to neutralize tagging on specific layout elements
• Implement PDF Type 0 (Sampled) Functions (chapter 7.10.2 of 32000-1_2008)
• In the method ImagePdfBytesInfo.decodeTiffAndPngBytes when the colorspace is a separation color space don't throw an exception but recalculate the image pixels to the alternate colorspace of the separation color
• Update CMap files in font-asian package

Bugs

• Smart mode copying merges GoTo actions with different explicit destinations into a single PDF object
• PdfDocument.copyPagesTo was creating corrupt PDFs when there was a button widget whose action is to jump to another page within the same document
• When merging using UseSmartMode() layers with identical names were discarded
• Result of text extraction differs from the original document text for CJK fonts (Identity-H/V encoding)
• table.createRendererSubTree() is producing an incorrect height calculation for the occupied area BBox. If we set the cell height to the calculated value, then text is being clipped on the final output