Minimizing the pain in implementing printable reports

How do you minimize the pain in your development process when it comes to reporting?

For web frameworks, there is a pretty straightforward way to both produce content as well as graphically design it; content is represented semantically through HTML, and the design is separately specified through CSS. And browsers are fairly consistent with how they render the output (and the inconsi开发者_开发问答stencies are well-known and can be planned for). There are even WYSIWYG editors to help out less-CSS-savvy graphical designers.

But what do we do about print content?

At one company, I created a process that worked like this: A script generated a semantic representation through XML. The XML was passed through XSLT to generate an XML-FO document. Then, this was passed to another tool (Apache FOP, I believe) to generate a PDF. This worked well for that company.

At this company, however, output appearance matters to management, and we have a graphical designer. Currently, we are using a reporting tool (XtraReports from Developer Express, version 8.1). It isn't bad; it outputs to a variety of formats, has a WYSIWYG designer, reports are implemented through C# classes, and it supports data binding to data sets (unfortunately, not POCO's). However, we have some major pain points with this setup:

• The reporting framework has major limitations on how you can lay out and group your reporting bands
• Presentable elements, especially charts, lack the capabilities we need to fine-tune and achieve the look of our mock-ups.
• There is no good way to share styles and layout among reports akin to what we can get through CSS.
• Good composability of reusable parts is very hard to implement. So we end up with a lot of copy & paste inheritance of functionality; this is bad news whenever we need to make sweeping changes across all reports.

Now, maybe there's some kick-ass framework out there that can eliminate the pains of reporting frameworks, but I assume that they all have their weaknesses. Do you have a framework or process that works well for you and reduces the pain points inherent in reporting?

---

Prince XML is a really cool tool which allows you to use HTML or XML styled with CSS (including CSS paged media for printing) and generate PDFs from it.

---

Option #1 : Adobe Acrobat is really nice. You can design form enabled PDFs and then use something like PDFSharp to manipulate the PDF document. You can create template PDF's that you dump your generated stuff into. I've done this before and it was pretty successful. I also used POCO objects nicely.

Option #2 : You could start creating XPS documents, which is XML based anyways. And they can be easily converted to PDF if necessary.

Option #3 : Run for your life.(might not be an option)

---

i-net Clear Reports is a nice product. It's based on Java but you can also work with ASP.NET. There is a bridge. The .NET version is in work if you want work with POCO. Because the Java version can work with POJO that the coming .NET version will also work with POCO.