iTextSharp 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. 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 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.

iTextSharp 5.5.6

If you compare the changelogs for iText 5.5.6 with previous change log entries (for instance the one for iText 5.5.5), 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 (search for the git repositories, the svn repository is no longer updated) and to GitHub. 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. 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.

iTextSharp 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, 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) attacks that were reported on December 31, 2014. 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!

iTextSharp 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 PdfPTables 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).

iTextSharp 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.

iTextSharp 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.

iTextSharp 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.

iTextSharp 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, iText RUPS and XFA Worker (the latter is a closed source project).

RUPS was originally an acronym for Reading and Updating PDF Syntax, but up until now, it wasn't possible to Update a PDF file. Michaël Demey 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.

iTextSharp 5.4.5

iTextSharp_5_4_5

Updated Dutch translations