.

« FeedJournal.com | Main | I am a father! »

Wednesday, May 24, 2006

Choosing FeedJournal output format

When I first started spawning ideas about an RSS reader that would print the articles as a regular newspaper, I had a tough choice to make between output formats. My main options were:

  • HTML with CSS
  • Microsoft Word
  • Adobe's PDF format

There are also other document formats (RTF, etc) I considered but quickly rejected.

Let's look at each of these formats in order to see how I came to my final decision. The main factor guiding my choice was having the result look professional, with justified multicolumn paragraphs for instance.

The thing is that I would love to be creating an HTML page with CSS styling because of the portability. Basically the full published issue would be contained in one HTML page (with a few hyperlinked image files). This package would open on any computer with a decent web browser. Also, page breaks are readily available using the <br style="page-break-before:always;"> tag. However, the problem comes when trying to figure out the size a chunk of text will use when creating the pages.

The MS Word or RTF choices are immediately more attractive because they expose an API to create the documents, which should produce more maintainable source code. On the other hand the Word format is a closed format as well as the API.

Then we have the third option, PDF, which on the surface doesn't offer any benefits over MS Word (besides being an open format), only a more quirky client which by default takes ages to start up. But some research-hours later and after finding iTextSharp I reached the conclusion that PDF is the way to go for FeedJournal! iTextSharp is an excellent open-source component written in C# for generating PDF files using the .NET platform. Using an open-source API for creating the PDFs is a significant improvement for a developer, allowing deep debugging of code sections and finding the root cause of exceptions. And should I find a bug or limitation in the component I have full control over the source and can fix it without being dependent on others.

Besides, the startup performance of Adobe Reader is easy to cure. And if you are completely allergic to Adobe Reader there is a beautiful lightweight freeware alternative in Foxit Reader.

Then of course there is the additional benefit of supporting the new ubercool eInk gadgets hitting the market right now, with all of them supporting PDF natively. More about these in future blog posts.


© Jonas Martinsson 1995-2006