
Before we get into the nitty gritty of parsing the HTML so that we can create PDF code from it, it is important that we develop the concept of how text layout works in iTextSharp. So today we will cover those basics.
The first type of element we want to deal with when we parse our HTML into a PDF is the Paragraph element.
When we get to actually parsing our HTML to PDF code we will use the Paragraph object for all of our block elements. This allows us to add other Paragraphs and Chunks into it which we can format.
A Chunk is our second object that we will be using. The Chunk is the main object that will allow us to format the font. In fact, even if our block element specifies some sort of specific font, the font doesn’t actually get applied in the code until we add the text.
Typical code to place text into a PDF document would look something like this
1  | p = new Paragraph(new Chunk("text that needs a font",  | 
where “ct” is an object of type ColumnText that we discussed last week.
The only other two classes we need to discuss are the list classes. We use the List to create an item that will handle both the OL and UL tags. The ListItem class will handle the individual items within the list. The List constructor handles which of the two types of list we are dealing with by specifying true or false in the first parameter, numbered.
I have not yet added the ability to handle tables to my HTML parser mainly because I have not had the need. I think once I show you how to create tables and how to parse HTML you should be able to handle adding table parsing code yourself.



 When I first started generating PDFs dynamically, I was overwhelmed by the complexity of the API.  Not just with iTextSharp, but it seemed that all of the APIs were complex. In looking through the API and comparing it to what I was actually trying to accomplish, I found there was a very small subset of classes and methods that I needed to use to accomplish the task at hand.  Now that I’ve learned more, I still use this same subset of commands for 90% of what I need to do in iTextSharp.  The reason we produce PDFs programmatically at all is because we need to dynamically generate some information on the page.  Most of the time, this information comes out of a database and gets placed on the same location of the page each time the page is generated.  The rest of the information is static. So what I normally do is have my designer or project manager create a PDF for me with form fields located where he wants the information to go.  Using the form fields, he can define the font, size, color, and position he wants to display the text with.  All I have to worry about is getting the text into the field. This works out nicely because once I’ve filled in the forms, he can move them around until he’s happy with them without asking for my help. We’ve already covered 
 There are several libraries on the market now that allow you to create PDF documents from your .NET applications.  The one I’ve chosen to use is 
 On Monday, I was corrected in my assertion that creating multiple empty strings would create multiple objects.  Turns out the compiler automatically puts all of the strings that are exactly the same in a “string pool” so that there is only ever one empty string in the entire application you’ve created.
I recently read an article that argued that “” is “Better than String.Empty”
  I just read a post by Casademora on “public abstract string[]  Blog()”
 So here’s the question: