search

Chiencc / Spring5-Login_Prioritize-Sample

0 stars 0 forks source link

Update dependency com.itextpdf:itextpdf to v5.5.13.3 #122

Open renovate[bot] opened 2 years ago

renovate[bot] commented 2 years ago

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
com.itextpdf:itextpdf (source) 5.3.4 -> 5.5.13.3 age adoption passing confidence

Release Notes

itext/itextpdf ### [`v5.5.13.3`](https://togithub.com/itext/itextpdf/releases/5.5.13.3) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.13.2...5.5.13.3) Since the release of iText 5.5.13 the iText 5 product line has transitioned to be in maintenance mode, meaning it only receives security related releases. While iText 5 is now EOL, we want to make sure that our users who have developed their solutions using iText 5 can safely continue using it. For this particular release, we’ve backported a security bug fix from iText 7.2.0 and 7.1.17 to resolve a vulnerability that allowed the use of GhostScript in an unpredictable manner. See [CVE-2021-43113](https://nvd.nist.gov/vuln/detail/CVE-2021-43113) for more information. In addition, we have updated the Apache XML Security for Java (org.apache.santuario:xmlsec) dependency to version 1.5.8 from version 1.5.6. The Bouncy Castle Crypto API for Java has also been updated to version 1.67 due to a flaw in the OpenBSDBCrypt.checkPassword() method present in 1.65 and 1.66. This was disclosed in [CVE-2020-28052](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28052), see the link for more details. Note that if you use some of the older Java versions (Java 1.5-1.8) you might need to update the bouncy castle dependency to a different specific distribution. On Maven it's org.bouncycastle.bcprov-jdk15to18. From https://www.bouncycastle.org/latest_releases.html: "Further Note (users of Oracle JVM 1.7 or earlier, users of "pre-Java 9" toolkits): As of 1.63 we have started including signed jars for "jdk15to18", if you run into issues with either signature validation in the JCE or the presence of the multi-release versions directory in the regular "jdk15on" jar files try the "jdk15to18" jars instead." An example of an exception which might occur if the “standard" bouncy-castle distribution is used together with older Java versions: > java.security.NoSuchAlgorithmException: 1.2.840.113549.3.2 KeyGenerator not available. ### [`v5.5.13.2`](https://togithub.com/itext/itextpdf/releases/5.5.13.2) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.13.1...5.5.13.2) ##### core - security update of bouncy castle dependency ### [`v5.5.13.1`](https://togithub.com/itext/itextpdf/releases/5.5.13.1) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.13...5.5.13.1) ##### core - security fix for clearer signatures validation - security improvement around decompression bombs ### [`v5.5.13`](https://togithub.com/itext/itextpdf/releases/5.5.13) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.12...5.5.13) iText `5.5.13` is a maintenance release that rolls up 4 bugfixes for [iText 5 Core](https://itextpdf.com/itext-5-core) from the past 5 months: - As of this release XFA Worker is no longer supported on .NET 2.0 - instead you need to use .NET 4.0. - Support has been added for License Key Library 3.0.1. Users on License Key Library 1.0.x should migrate to 3.0.1. - 3 bugfixes for iText 5 Core `5.5.13`. - 1 bugfix for [XFA Worker](https://itextpdf.com/Products/xfa-worker) `5.5.13` (commercial add-on, not on GitHub). Please be informed that at the same time we release [pdfXFA](https://itextpdf.com/itext7/pdfXFA) `1.0.3`, an add-on for iText 7. All bugfixes for XFA Worker `5.5.13` were ported to pdfXFA `1.0.3`. No new functionality has been added since [`5.5.11`](https://itextpdf.com/release/iText5511). The full list of changes can be found in the [changelogs](https://itextpdf.com/blog/itext-release-5513-changelog) and the release in our download hub for [Java](https://developers.itextpdf.com/itext-java) and [.NET](https://developers.itextpdf.com/itextsharp-net). If you use Maven, then you can download iText from the Central Repository by adding one or more of the following XML snippets to your `pom.xml`: com.itextpdf itextpdf ${itext.version} com.itextpdf itext-pdfa ${itext.version} com.itextpdf itext-xtra ${itext.version} com.itextpdf.tool xmlworker ${itext.version} Still questions about the release, don't hesitate to [contact us](https://itextpdf.com/contact). ### [`v5.5.12`](https://togithub.com/itext/itextpdf/releases/5.5.12) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.11...5.5.12) iText `5.5.12` is a maintenance release that rolls up 22 bugfixes for iText 5 Core from the past 5 months: - 22 bugfixes for iText 5 Core 5.5.12. - 6 bugfixes for XFAWorker 5.5.12 (Commercial add-on, not on GitHub). No new functionality has been added since `5.5.11`. At the same time we also release pdfXFA 1.0.2, an add-on for iText 7. All bugfixes for XFAWorker 5.5.12 were ported to pdfXFA 1.0.2. ### [`v5.5.11`](https://togithub.com/itext/itextpdf/releases/5.5.11) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.10...5.5.11) iText `5.5.11` is a maintenance release that rolls up 28 bugfixes from the past 5 months. No new functionality has been added since `5.5.10`. ### [`v5.5.10`](https://togithub.com/itext/itextpdf/releases/5.5.10) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.9...5.5.10) Changelog: http://itextpdf.com/changelog/5510 Release Notes: http://itextpdf.com/release/iText5510 Download: https://github.com/itext/itextpdf/releases/tag/5.5.10 ### [`v5.5.9`](https://togithub.com/itext/itextpdf/releases/5.5.9) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.8...5.5.9) Changelog: http://itextpdf.com/changelog/559 Release Notes: http://itextpdf.com/release/iText559 Download: https://github.com/itext/itextpdf/releases/tag/5.5.9 ### [`v5.5.8`](https://togithub.com/itext/itextpdf/releases/5.5.8) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.7...5.5.8) For this release, we combined the `itextpdf`, `pdfa`, `xtra` and `xmlworker` repositories on [GitHub](http://github.com/itext/itextpdf). You no longer need to download **XML Worker** separately, it is included in the ZIP file below. You'll have to make small changes to your development environment if you import the iText source code. A new site, a new release! We've been working very hard on a new web site that would contain more [code samples](http://developers.itextpdf.com/examples) and [answers to questions](http://developers.itextpdf.com/frequently-asked-developer-questions). We've also made it easier to find the information you need by creating different, easy-to-understand categories, but also through better search functionality and the use of tags. iText 5.5.8 fixes a problem with digital signatures that was accidentally introduced in version 5.5.7. While we were at it, we also improved the verification of OCSP responses. There were also problems when signing PDFs that are compliant with the PDF/A-2, PDF/A-3 and ZUGFeRD standard. Those are now fixed. Other improvements involve: - Fonts: there were issues with some Noto fonts, we fixed the range of characters in the ToUnicode table, we provided a fallback mechanism in case of absent OS/2 tables, - Annotations: fixed some scaling issues and some flattening problems when skew and rotation are involved, - PdfReader: fixed partial reading when a PDF file is imported as a byte array, - Tagged PDF: fixed a problem with the structure tree when using page events, - Page labels: we received code contributions from Nick Park that improve page label extraction. We also have a new [RUPS](https://togithub.com/itext/rups) release. You can now click a stream in tree view to inspect its contents in a new window. This allows the user to keep a stream open while looking at other information such as the resources (fonts, XObjects, images,...) used by the stream. For the full list of updates, see the [Changelog 5.5.8](http://itextpdf.com/changelog/558). ### [`v5.5.7`](https://togithub.com/itext/itextpdf/releases/5.5.7) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.6...5.5.7) There's a new 60-page tutorial in the works about creating e-Invoices with iText. This book will be presented at Adobe's Headquarters in San Jose at the [PDF Association's PDF Technical Conference](http://www.pdfa.org/event/pdf-technical-conference-2015/). In the pdfa jar of iText 5.5.7, you'll find code that allows you to create ZUGFeRD invoices as a PDF document with an XML attachment that complies either with the ZUGFeRD Basic profile or the ZUGFeRD Comfort profile. All you need to do to create the XML, is to implement either the `BasicInvoice` or the `ComfortInvoice` interface. These are invoices that consist of nothing but `getX()` methods in which you provide the content of your invoice (such as seller, buyer, invoice lines,...). The functionality is currently released in beta, [let us know](http://itextpdf.com/contact) if you want more info before the official release of the tutorial. This release also brings several improvements, especially in these areas: - The CleanUp functionality: several bug fixes; we've also resolved some inconsistencies between iText and iTextSharp. - Forms: fixed some problems with special (or missing) fonts, fixed some edge cases when merging forms. - Tables: fixed edge case errors, for instance problem: - with skip first header/last footer, - when splitting rows, - regarding performance issues with nested tables. - Reading PDF: better exception messages when "bad" PDFs are being read. For instance: we've found a PDF that had (illegal) circular references that resulted in an endless loop. We can now fail early before the JVM goes out of memory. - Digital signatures: added functionality to manage the field lock dictionary, solved a problem with the signing time attribute, and other fixes We noticed some differences when using iText with Java 7 versus using iText with Java 8. These are now solved. We've added the `PdfASmartCopy` class. You can now choose for external caching when creating PDF/A (to save memory). We've also introduced some improvements to `PdfStamper`: you can now add named destinations, and you can incrementally update a file on disk (if you want to save memory). For the full list of updates, see the [Changelog 5.5.7](http://itextpdf.com/changelog/557). ### [`v5.5.6`](https://togithub.com/itext/itextpdf/releases/5.5.6) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.5...5.5.6) If you compare the changelogs for [iText 5.5.6](http://itextpdf.com/changelog/556) with previous change log entries (for instance the one for [iText 5.5.5](http://itextpdf.com/changelog/555)), you immediately notice that we're using a completely different style. We have successfully moved from Subversion on SourceForge as our main code repository to Git on a private GitLab server. From our GitLab server, the source code is now distributed to [SourceForge](https://sourceforge.net/projects/itext/) (search for the [git repositories](https://sourceforge.net/p/itext/\_list/git), the svn repository is no longer updated) and to [GitHub](https://togithub.com/itext). Changelogs are now mostly generated automatically based on the git logs. This move immediately triggered some pull requests with code contributions from developers like you. One of these contributions made it into the final release: PdfGraphics2D now has support for CMYK. For this release, we have continued working on the CleanUp functionality in the xtra package. We now support redaction that involves lines and shapes. To achieve this, we enhanced the parser package so that it now also produces parsing info about operators such as moveTo, lineTo and stroke. We used a third party clipper library to do geometric calculations. There were also some improvements with respect to Arabic text. We are looking at fonts in general, and we are making good progress, but please don't expect the results in the next couple of releases. Better font support requires a lot of changes at the lowest level of iText and we won't release new font functionality before 2016. As always, we've added plenty of improvements and applied several bug fixes based on feedback from our paying customers and based on feedback from users on [StackOverflow](http://stackoverflow.com/questions/tagged/itext). Note that the changelogs contain links to JIRA: that's our closed ticketing system. Only paying customers have access to this issue tracker, but most of the tickets are only visible to core iText developers. ### [`v5.5.5`](https://togithub.com/itext/itextpdf/releases/5.5.5) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.4...5.5.5) We're releasing iText 5.5.5 on iText's 15th birthday: February 14, 2015 and if we take a look at the [changelog](http://itextpdf.com/changelog/555), we see that we're making progress in a couple of related areas. Returning topics are **text extraction**, **compare tool** and **clean-up functionality**. The common denominator of these three evolutions is **PDF parsing**. ##### Text extraction: We have fixed a bug that was introduced very recently and that was reported by many different developers. This bug caused an ArrayIndexOutOfBoundsException when an empty String was encountered. We improved parsing of Type3 fonts and we improved parsing of Unicode fonts. Documents that used to result in nothing but white space, are now converted to actual text. Of course: there will always be broken PDFs that can never be parsed correctly, no matter which tool you use. ##### Compare tool: As parsing improves, we can come up with better ways to compare PDFs. We have a large suite of tests that generate PDF documents and then compare the result with a reference PDF. This isn't trivial as two PDFs that are created using the same code are never identical by design (that's inherent to the PDF specification). There are different strategies one can use to compare such PDFs and we are constantly improving our compare tool by adding new strategies. ##### Clean-up functionality: This is a work in progress that was started in iText 5.5.4. At that time, the development was done in the Java version of iText only. We have now ported this functionality to C# and we have improved the functionality. For instance: whereas we only allowed redaction of text in 5.5.4, we now also allow redaction of images. The work isn't finished yet: we still have several edge cases to fix and redaction of curves isn't covered yet. Apart from these three major areas, we also fixed a number of issues that were reported. If you use the XMP functionality, it is important for you to upgrade to protect yourself against the [XML External Entity (XXE)](https://www.owasp.org/index.php/XML_External_Entity\_%28XXE%29\_Processing) attacks that were reported on [December 31, 2014](https://www.owasp.org/index.php/XML_External_Entity\_%28XXE%29\_Processing). We also fixed some problems related to Tagged PDF and fonts. Finally, let's take a look at the other iText projects: - We won't make a RUPS release, because no new functionality was added to RUPS. - The new XML Worker version will only bring a handful of improvements (that might be important if you use tables) - As usual, users provided us with a new series of XFA forms with special features that we integrated into a new XFA Worker release. That's all for iText 5.5.5. Let's start working on iText 5.5.6! ### [`v5.5.4`](https://togithub.com/itext/itextpdf/releases/5.5.4) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.3...5.5.4) We're releasing iText 5.5.4 on December 17, exactly 3 months after the previous release. If you scroll down in the changelog, you notice that once again, XFA Worker has received plenty of attention. Our initial XFA customers are very happy with the functionality we provided in previous versions, but new XFA customers are discovering more and more features in the XFA spec and we're consistently adding these features to XFA worker. But let's focus on the open source part of iText: The most promising new feature is hidden in a single line: Added PDF "clean up" functionality that can be used for redaction. We don't have any examples yet, but it seems that more and more people are asking for functionality that allows you to remove content from a PDF. With "to remove", we don't mean "covering it with a colored rectangle", but to actually remove content from the PDF's content stream. Currently, we allow removing content based on redaction annotations as well as based on rectangles you can define in your code. This functionality is currently only available in the Java version, it hasn't been ported to C# yet (it's on our TODO list). Once we have some examples, we count on your feedback to improve this functionality. Our efforts with respect to PDF/A support seem to be appreciated. We've received interesting feedback and... some bug reports. We fixed problems with images in PDF/A-1A, problems with combinations of PDF/A-2 and signatures, we've added ZUGFeRD extension levels, and so on... On a related note: we've added some fixes that help people to avoid a common pitfall when manipulating a Tagged PDF document. When creating PDF from HTML, we now take the alt value of an tag into account. Some languages have a "right to left" writing system that can be set with the `dir` attribute in HTML. We've now added support for this attribute in XML Worker, and while we were at it, we've added support for justified text when writing from right to left. We've discovered that some people were using the `LargeElement` functionality for `PdfPTable`s in a way that made them lose a row and/or a header. We applied a fix so that this wouldn't happen anymore in the future. These are the most important enhancements and fixes, you can take a look at the changelog for more info. We've improved `PdfGraphics2D` when using font families for which there are no fonts available for every style (for instance: no bold font, no italic font, or not bold-italic font). ### [`v5.5.3`](https://togithub.com/itext/itextpdf/releases/5.5.3) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.2...5.5.3) In the previous release dating from two months ago, we focused on XML Worker parsing HTML and CSS. In today's release, you'll discover that we focused mainly on XFA Worker. XFA is a closed source add-on written on top of iText. We've made the JavaScript interpretation more flexible, fixed page breaking mechanisms and issues with tables, and so on... All of these changes resulted from support tickets posted by customers. This doesn't mean we didn't do any work on the other iText products: - **iText**: we've solved some problems when merging PDFs with interactive features using PdfCopy. We've added support for flattening annotations for which appearances were defined. We've made form-filling less dependent from the NeedAppearances flag to avoid confusion. We've fixed a problem that occurred when the rectangle of a field's widget annotation differs from the bounding box of its appearance. We've discovered that our PDF/A checker was too strict in some cases. We've fixed a problem with Datamatrix matrix codes. And we've further improved the PDF parsing functionality concerning inline images. - **RUPS**: We've made RUPS more user-friendly by adding short-cuts and menu entries for instance to open the PDF in a PDF viewer. We've also made it easier to navigate through a document. - **XML Worker**: We've added some extra CSS functionality involving images that was overlooked in the previous release. Now we'll start preparing for our Java One tutorial session. If you're in San Francisco for the event, make sure you visit the iText booth. http://itextpdf.com/changelog/553 ### [`v5.5.2`](https://togithub.com/itext/itextpdf/releases/5.5.2) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.1...5.5.2) Two months have passed since iText 5.5.1 and we're ready to release iText 5.5.2. Although the changelog may seem relatively short, there's one line in specific we've put a lot of effort into: Major improvements to the CSS parser. This is actually a complete rewrite of the CSS functionality, resulting in much better interpretation of CSS syntax. You'll find these changes in iText's XML Worker. The HTMLWorker class that was shipped with iText core was finally deprecated. We noticed that many people are starting to be aware of Tagged PDF, PDF/A and PDF/UA. We received numerous questions on the subject of merging Tagged PDFs, more specifically PDF/A compliant documents. This wasn't supported in previous versions and it's also kind of tricky because you can't just mix the different flavors of PDF/A. For instance: you shouldn't expect that a PDF/A-1B document merged with a PDF/A-2A document will result in a PDF/A-2A document. Nevertheless we've added a class PdfACopy that allows you to make combinations that make sense and that throws an exception when you're trying to make a combination that doesn't. We made sure that you can't use the PageStamp functionality when using PdfCopy in tagged mode. This way, we avoid that people don't introduce untagged data out of ignorance regarding the nature of Tagged PDF. PdfCopy now also supports merging fields with tags. When parsing documents with Type 3 fonts, we used to return space characters because Type 3 fonts are user defined fonts where a random character is mapped to a custom made glyph. We've changed this so that iText returns the characters that were stored inside the PDF. This doesn't always make sense because it can result in a set of random characters, but it is more in line with what people expect when parsing a PDF file that contains Type 3 fonts. Finally, we've introduced functionality to cache objects to improve the PDF writing process, and we've improved the generic testing framework. ### [`v5.5.1`](https://togithub.com/itext/itextpdf/releases/5.5.1) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.5.0...5.5.1) About a month ago, Adobe announced that it would never support XFA forms in Adobe Reader on mobile platforms (see blogs.adobe.com on April 16, 2014. XFA forms are much more dynamic and interactive than ordinary PDF forms (AcroForms) and some mobile operating systems place restrictions on what can be done on a mobile device. > This makes it very difficult (impossible actually) to provide the same dynamic PDF experience you expect on the desktop across all mobile devices using PDF. As a result, Adobe Reader Mobile does not support XFA based PDF’s created in the LiveCycle Designer and it will not provide this support in the future. Does this mean XFA is no longer important? On the contrary! A year ago, our colleagues at IDR Solutions already explained why XFA is important on their blog. But then how are we going to present these forms on mobile devices? There are basically two options. Adobe and IDR Solutions offer the interactive solution, converting XFA to HTML 5 for consumptions on the mobile device. We offer the non-interactive solution, where we flatten the XFA form into an ordinary PDF document that can be viewed in any PDF viewer. The former solution is recommended when the form needs to be dynamic and when you need the form to respond to user input; the latter solution is recommended when you want to display, archive, secure the data in the form. When you look at the changelogs of iText 5.5.1, you immediately see that we've invested in even more development of XFA Worker. Now that XFA Worker creates Tagged PDF, our customers started experimenting with the generation of PDF/A and PDF/UA from XFA forms. This resulted in some extra enhancements and bug fixes. For instance: we discovered that we didn't fully support PDFs that comply with PDF/A as well as PDF/UA from XFA. This is now fixed. Apart from further PDF/A enhancements, we introduced a conformance level that allows you to create documents that are in compliance with the ZUGFeRD standard (for instance: invoices). The ZUGFeRD standard is a superset of PDF/A-3 where you combine a human-readable PDF with a machine-readable XML attachment. Talking about XML: We have also fixed a number of bugs in XML Worker. Some combinations of tags gave odd results, and there was a problem with tables and rowspans. As we speak, the ISO committee for the PDF standards is meeting in South-Africa. One of the new standards that is being discussed involves XFDF. This new standard introduces much needed documentation for the Forms Data Format in general. We noticed that FDF is used quite frequently and we added some new functionality. Important: the input source is no longer closed automatically when using FdfReader; you're responsible for closing that stream in your code. Finally, we still find ways to improve RUPS. Not a day goes by without us using RUPS to look inside a PDF. ### [`v5.5.0`](https://togithub.com/itext/itextpdf/releases/5.5.0) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.4.5...5.5.0) In 2013, we had 6 iText releases, numbered from iText 5.4.0 to 5.4.5. For the first release of 2014, we thought it would be a good idea to switch to iText 5.5.0. That way, we get an idea of the release year, just by looking at the number. But let's take a look at what's more important: what's new in this release? We received plenty of feedback regarding the accessibility functionality that was introduced last year. The PDF/UA spec is relatively new and the ISO committee is still fixing a couple of issues that were discovered in the first version. The same goes for iText. For instance: we discovered that backgrounds added to Chunks weren't marked as artifacts, attributes for Form XObjects weren't written correctly, and so on. We also received some bug reports after the PdfCopy update, especially when merging forms. We've fixed these and a couple of other bugs. For example: there were problems if the NeedAppearances flag was set for one of the original forms. Furthermore, we've won another battle in the never-ending struggle to support different flavors of the TIFF format. We've solved 56 issues in total! We've extended the testing infrastructure. The existing CompareTool class has been moved to a separate testutils package. And we've implemented the suggestion made by Valentin Ivanov and David Hook, allowing the use of an external decryption process (sorry for the delay, guys). We've also released [XML Worker](http://itextpdf.com/Products/xml-worker), [iText RUPS](http://itextpdf.com/Products/itext-rups) and [XFA Worker](http://itextpdf.com/Products/xfa-worker) (the latter is a closed source project). RUPS was originally an acronym for **R**eading and **U**pdating **P**DF **S**yntax, but up until now, it wasn't possible to Update a PDF file. [Michaël Demey](https://togithub.com/michaeldemey) has now introduced some functionality that allows you to change a dictionary (add, update, delete keys) and to save an altered PDF. He added more interactivity (short cut keys) and a way to consult the content of a PDF page as plain text. As for XFA Worker, more and more customers are using dynamic forms as templates and XFA Worker to populate these templates with data with a PDF (or even a PDF/A Level A and PDF/UA) documents as final result. We also have an increasing demand for trial licenses, resulting in excellent reports of small features that aren't supported yet. In answer to the requirements of our paying customers, we've started developing formcalc support (the sum() method and some arithmetic functions). We received kudos for our work on XFA Worker from our customer at the US Courts, and we suddenly realized that prospective customers weren't able to see the progress on this product. With this release, we're also publishing the changelog for this add-on for iText. ### [`v5.4.5`](https://togithub.com/itext/itextpdf/releases/5.4.5) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.4.4...5.4.5) The work that was planned for iText 5.4.4, but postponed due to a customer priority, has now been done: we have completed support for PDF/A, more specifically PDF/A-2 and PDF/A-3. XAdES-EPES support has also been added. Apart from the work that was scheduled, we've also fixed some iText 5.4.4-related issues that were reported to us by our customer; the new PdfCopy functionality to preserve the structure tree as well as the interactive form fields should now be ready for use. At the same time, some other PDF/UA-related issues were fixed, even in iText RUPS. Other improvements include the parsing functionality and an extra digital signatures feature that allows you to add information about the application that signed the PDF to the signature dictionary. As always, we've also fixed some bugs, for instance in XML Worker where we still experienced some problems with images in cells and with the order in which CSS styles are processed. ### [`v5.4.4`](https://togithub.com/itext/itextpdf/releases/5.4.4) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.4.3...5.4.4) http://itextpdf.com/changelog/544 ### [`v5.4.3`](https://togithub.com/itext/itextpdf/releases/5.4.3) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.4.2...5.4.3) http://itextpdf.com/changelog/543 ### [`v5.4.2`](https://togithub.com/itext/itextpdf/compare/5.4.1...5.4.2) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.4.1...5.4.2) ### [`v5.4.1`](https://togithub.com/itext/itextpdf/compare/5.4.0...5.4.1) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.4.0...5.4.1) ### [`v5.4.0`](https://togithub.com/itext/itextpdf/compare/5.3.4...5.4.0) [Compare Source](https://togithub.com/itext/itextpdf/compare/5.3.4...5.4.0)

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

This PR has been generated by WhiteSource Renovate. View repository job log here.