I'm wondering what is the best/easiest way to design a PDF document? Is it remotely legit to actually design a whole PDF document with iTextSharp with code (i.e not loading external files)? I want the final result to look similar to a web page with various colors, borders, images and everything.
Or do you have to rely on other documents like .doc, .html files to achieve a good design? Originally I thought that I would use HTML markup to generate a PDF, but why even use a HTML markup or a template file to create the PDF design when I could just do it right within the PDF without having to rely on on various files that serves no real purpose.
Is it possible to generate and design big PDF documents using code and are there any more proper guides or similar with all the various commands to generate texts, images, borders and everything since I have no real clue about generating PDF with code.
The question is very broad, so I can only give you a very broad answer.
Option 1: you create your layout by using iText's high-level objects. There are countless applications out there that are using
PdfPTable to generate complex reports. For instance: the time tables for a German Railway company are created from scratch through code; the invoices for a Belgian Telco company are created this way,... The advantage of this approach is that you can really fine-tune the layout. The disadvantage is that you need to change source code as soon as you want to change the layout.
Option 2: you create your layout by creating an AcroForm template. Every field in this template has a name and is visualized at exact positions (defined by its coordinates) on specific pages. The code to fill out such a form consists of only a handful of lines. Whenever you need to change the layout, you alter the AcroForm template. You do not need to change your code. The disadvantage is that AcroForms are very static. Compare it to a paper form: you can't insert a row in a paper form either.
Option 3: you create your data in XHTML format and your styles in CSS. A Belgian printing company responsible for creating invoices for its customers is streaming data into very simple HTML files involving a sequence of tables that never span more than a handful of pages. These files are then fed to iText's XML worker along with a CSS that is different for each of its customers. The advantage of this approach is that no extra programming is needed when a new customer joins. It's just a matter of creating a new CSS. The disadvantage is that you are limited by the HTML format. Elementary logic also tells you that you shouldn't expect URL2PDF: have you ever tried printing a website? Well, the bad quality of that print should give you an indication of the problems you'll encounter when trying to convert HTML to PDF. If you anticipate them, you can get good results. If you don't: it's a poor craftsman who blames his tools...
Option 4: define your template using the XML Forms Architecture (XFA). Such templates are usually created using Adobe LiveCycle Designer. An XSD is fed into LC Designer and the result is an empty form where the PDF format acts as a container for an XML stream. You can then use iText to inject your custom XML containing data that conforms with the XSD into the PDF and you can use XFA Worker to flatten such a form. XFA Worker is only available as a closed source product (givers need to set limits because takers rarely do).
Option 5: right now XML Worker is used to convert XHTML+CSS and XFA to PDF (ordinary PDF, PDF/A, PDF/UA). You could use the generic XML Worker engine to support your own XML format. The advantage would be a very powerful engine that you can tune to meet your exact needs. The disadvantage is that this involves a serious up-front development investment.
Option 6: use a third party tool to define the template and a third party server that uses iText under the hood to create PDFs based on the template. An example of such a third party tool is Scriptura developed by Inventive Designers. There are other tools, but Inventive Designers is a customer of iText and we know that they are using iText correctly whereas we don't have this guarantee from other vendors.