![]() In iText 7, you have a Table and Cell object, and when you set a different font for the complete table, this font is inherited as the default font for every cell. ![]() If you wanted every cell to contain text in a font different from the default font, you needed to set that font for the content of every separate cell. The iText objects were completely redesigned to better match HTML tags and to allow setting styles “the CSS way.”Īs an example, in iText 5, you had a PdfPTable and a PdfPCell object to create a table and its cells. The layout is created by traversing that tree, an approach that is much better suited to dealing with HTML to PDF conversion. When a document is created with iText 7, a tree of renderers and their child-renderers is built. IText 7’s layout engine and the new Renderer framework was now designed around a block-based approach, taking its inspiration from HTML. It also integrated jsoup, meaning you didn’t need to call it separately and so all HTML would be cleaned up before converting to PDF. To that end, we introduced the pdfHTML add-on which focused specifically on HTML to PDF conversion, leveraging the underlying improvements of iText 7. ![]() In addition to completely rewriting iText from the ground up, we also announced that in future, additional functionality would be added to iText in specific “add-ons” in order to keep the Core library clean and lean. The 2016 release of iText 7 brought significant changes. It was clear that if we really wanted to create a great HTML to PDF converter, we would first have to rewrite iText from scratch. In addition, many developers simply wanted to just convert HTML to PDF, instead of working with a fully-fledged generic XML framework. This, and several other design choices that made perfect sense when iText was first released in the year 2000, were still present sixteen years later. iText 5 was designed as a tool to produce PDF as fast as possible, flushing pages to the OutputStream as soon as they were finished, and its layout engine was a top-to-bottom, left-to-right line-based approach which did not lend itself well to tasks such as HTML conversion. XML Worker did suffer from the limitations of being based around iText 5 though. They then populated the HTML with data and used XML Worker to create the invoices as PDF documents, throwing away the original HTML. Rather than programming the design of an invoice in Java or C#, developers chose to create a simple HTML template defining the structure of the document, and some CSS defining the styles. A common use case was the creation of invoices. To clarify, it was designed to work with static HTML content, as opposed to dynamic (e.g. XML Worker wasn’t a URL2PDF tool though, and expected predictable HTML created for the sole purpose of converting that HTML to PDF. We know many developers who used XML Worker in combination with jsoup as an HTML2PDF converter. To solve this problem when confronted with incomplete HTML syntax, we advised the use of an HTML parser such as jsoup to tidy up the HTML before converting it to PDF with XML Worker. For instance: a single wasn’t allowed in your HTML you needed to have a, all tags needed to be closed and nesting of tags needed to be done correctly. ![]() However, XML Worker didn’t accept plain HTML, you had to provide XHTML instead. The focus of XML Worker was on extensibility rather than being an out-of-the-box HTML-to-PDF converter, and developers could use an implementation to convert XHTML (data) and CSS (styles) to PDF, mapping HTML tags such as, , and to iText 5 objects such as Paragraph, Image, and ListItem. In 2011, we released XML Worker as a generic XML to PDF tool, built on top of the then current version of iText: iText 5/iTextSharp. To avoid this frustration, the HTMLWorker class was deprecated many years ago. This led to some frustration because HTMLWorker didn’t support every HTML tag, didn’t parse CSS files, and so on. If you want to make a lot of font, font style and other property changes, it’s more convenient to start from a rich text HTML snippet rather than doing it all manually via the API. However, HTMLWorker was never meant to convert complete HTML pages to PDF, yet that was how many developers tried to use it. This was intended as a way to convert small, simple HTML snippets into iText objects, offering an easier way to style content. The roots of pdfHTML stretch back to iText 1.x where we introduced the HTMLWorker class. Now at version 3.0.0, this latest version brings some significant improvements and changes. For those unfamiliar with our HTML to PDF converter, in this article we’ll be taking a closer look at pdfHTML, its history within the iText PDF SDK, and what pdfHTML 3.x offers over previous versions. The latest 7.1.11 release of the iText 7 Suite included a major update to our most popular open source add-on, pdfHTML. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |