Sample-Ch01 Lowagie.Pdf

S AMPLE CHAPTER iText in Action by Bruno Lowagie Sample Chapter 1 Copyright 2007 Manning Publications brief contents PART 1 INTRODUCTION ......................................................1 1 ■ iText: when and why 3 2 ■ PDF engine jump-start 30 3 ■ PDF: why and when 73 PART 2 BASIC BUILDING BLOCKS ......................................97 4 ■ Composing text elements 99 5 ■ Inserting images 135 6 ■ Constructing tables 162 7 ■ Constructing columns 193 PART 3 PDF TEXT AND GRAPHICS ..................................221 8 ■ Choosing the right font 223 9 ■ Using fonts 257 10 ■ Constructing and painting paths 283 vii viii BRIEF CONTENTS 11 ■ Adding color and text 325 12 ■ Drawing to Java Graphics2D 356 PART 4 INTERACTIVE PDF .............................................393 13 ■ Browsing a PDF document 395 14 ■ Automating PDF creation 425 15 ■ Creating annotations and fields 464 16 ■ Filling and signing AcroForms 501 17 ■ iText in web applications 533 18 ■ Under the hood 562 iText: when and why This chapter covers ■ History and first use of iText ■ Overview of iText’s PDF functionality ■ Introduction to the examples in this book 3 4 CHAPTER 1 iText: when and why If you want to enhance applications with dynamic PDF generation and/or manipu- lation, you’ve come to the right place. Throughout this book, you’ll learn how to build applications that produce professional, high-quality PDF documents. More specifically, you’ll learn how to do the following: ■ Serve dynamically generated PDF to a web browser ■ Generate documents and reports based on data from an XML file or a database ■ Create maps and ebooks, exploiting numerous interactive features available in PDF ■ Add bookmarks, page numbers, watermarks, and other features to existing PDF documents ■ Split and/or concatenate pages from existing PDF files ■ Fill out forms, add digital signatures, and much more You’ll create these documents on the fly, meaning you aren’t going to use a desk- top application such as Adobe Acrobat. Instead, you’ll use an API to produce PDF directly from your own applications, which is necessary when a project has one of the following requirements: ■ The content needs to be served in a web environment, and PDF is pre- ferred over HTML for better printing quality, for security reasons, or to reduce the file size. ■ The PDF files can’t be produced manually due to the volume (number of pages/documents) or because the content isn’t available in advance (it’s cal- culated and/or based on user input). ■ Documents need to be created in unattended mode (for instance, in a batch process). ■ The content needs to be customized and/or personalized. This book is a comprehensive guide to an API that makes all this possible: iText, a free Java-PDF library. For first-time users, this book is indispensable. Although the basic functionality of iText is easy to grasp, this book lowers the learning curve for more advanced functionality. It’s also a must-have for the many developers who are already familiar with iText. With this book, they finally have in one place all the information previously found scattered across the Internet. Even expert developers are likely to discover iText functionality they weren’t aware of. The history of iText 5 In this chapter, you’ll learn how iText was born, and we’ll look at some real- world PDF files that were generated using iText. 1.1 The history of iText In the summer of 1998, the university where I worked1 was starting up a migra- tion project with the intention of redesigning a series of standalone programs used by the student administration. Up until then, entering the grades of students and calculating their final results at the end of the academic year was done using software that worked only on MS-DOS. Documents produced by this software could be printed on only one type of printer. This wasn’t an ideal way of working, to say the least. Teachers and their administrative staff were using all kinds of systems: Windows, Mac, Linux, Solaris, and so forth. Yet for one of the most delicate aspects of their job—grading students—they were still forced to use plain old DOS. The university decided it was high time to do something about this situation and hired two developers to create a completely web-based solution. One of them was (and still is) my colleague Mario Maccarini. The other one, as you’ve probably guessed, was me. Mario and I immediately started writing some Java servlets using Apache JSERV (it was the stone age of J2EE), and we proudly presented our first online lists with students, courses, and grades in the fall of 1998. It was just some ordi- nary HTML in a browser, but compared to the MS-DOS box, it was a big leap forward. Everybody was enthusiastic, until somebody asked one of the most cru- cial questions of the project: what did we, the developers, plan to do about the “document problem”? 1.1.1 How iText was born Have you ever tried printing an HTML document in Microsoft Internet Explorer (MSIE), Firefox, or Netscape? If so, you have a good idea of the problem we were facing. Every browser interprets HTML in its own way. A table in MSIE doesn’t look completely the same as a table rendered by Firefox. Using Cascading Style Sheets (CSS) can help you fine-tune the end result, but there’s another problem: The end-user can disable style sheets, change margins, add page numbers, and so forth. Moreover, just like with Microsoft Word documents, the end user can usu- ally change the content of an HTML document manually, using the application 1 ICT Department, Ghent University, Belgium. 6 CHAPTER 1 iText: when and why that renders the document. We wanted to avoid this, so we didn’t consider Word and HTML to be options. We needed a technology that allowed us to generate unalterable reports with a reliable layout. I didn’t know much about the Portable Document Format back then. I only knew it was supposed to be a read-only format and that you could make print- outs look exactly the way you intended to, regardless of the operating system and/or printer. When the document question arose, my answer was impulsive. Without fully realizing the consequences, I told the university committee, “We’ll produce PDF!” Mind you, it was a good answer, and it was well received. PDF is known as a widespread page-description language (PDL), and it’s a de facto industry stan- dard. It’s portable. It’s reliable. It prints really well. Almost everyone has the free Adobe Reader on their system. I assumed all of these fine qualities auto- matically meant there would be ample free or open source software available to produce PDF. Apparently I was wrong. I needed an API, a set of classes, preferably written in Java, and preferably open source, but in the winter of 1998, the only free Java- PDF libraries I found on the Internet weren’t able to provide the functionality required in our project. Only then did I become aware that I would have to write a PDF library myself if I wanted to keep my promise. During that period, I spent all my free time reading the PDF Reference. Within seven months of when we were hired, our new intranet application was brought into production at the university where I worked. Its main users were university professors, their proxies, and the administrative staff of the university. Registered users could log in to a personalized intranet page and do the following: ■ Get an overview of all the courses they were responsible for (as a teacher or a proxy) ■ Fetch (empty) grading lists in PDF with all the students enrolled for a specific course ■ Get an HTML form to submit grades to the server (this could also have been a PDF AcroForm—a form containing a number of fixed areas—or AcroFields, on one or more pages) ■ Get a completed version of the grading lists per course The history of iText 7 School administrators were also able to ■ Compose a curriculum for each individual student ■ Generate application forms for students to sign up for specific examina- tion periods ■ Calculate every student’s grade at the end of the academic year ■ Fetch lists with information on the complete year of study for different purposes: deliberation lists, proclamation lists, feedback for the students, and so forth ■ Generate official documents such as report cards and transcripts for the students Every document that needed to be printed was generated in PDF by a newly created library. I designed this set of classes in such a way that it would be usable in other projects, too. I was encouraged to publish the library as a Free and Open Source Software (FOSS) product even before our project went into production. That’s how iText was born. Almost immediately, many fellow developers started to use the library, contrib- uting source code at the same time. Paulo Soares was one of these early adopters. He joined the project in the summer of the year 2000 and is now one of the main developers of new iText features. He also maintains the .NET port iTextSharp. 1.1.2 iText today Nowadays, iText is used in many online and other services, directly or indirectly. You may have already used iText without being aware of it; a lot of software prod- ucts ship iText in their distribution. If you’ve created PDF documents using Mac- romedia ColdFusion, the file was probably generated by iText. If you’re creating reports with one of the most important reporting tools of the moment—Jasper- Reports or Eclipse/BIRT—you’ll see that iText is built in as its PDF engine.

Load more