bad UI for design, but it is free so..... frustration will continue
3 Answers:
Good question. I can think of a bunch of answers, all of them would be insulting, so I'll refrain.
What I WILL do though, is suggest very basic alternatives that work.
Firstly, groff. The original "run off" language is nearly 50 years old. It's stable and supports pretty millimeter precision. Despite being an esoteric language, it's simple to produce PDFs, as it adheres to the UNIX philosophy of simple text-based input/output protocols. It's almost a programming language (as is PostScript, the PDF predecessor), meaning you can write conditionals, loops, etc, in the report itself, rather than in the programming language generating the report (the choice is up to you). It's also very fast - I can produce a 32,000 page PDF in our database in less than 3 minutes. If you need more capacity than this, then you're likely in a big business with big bucks, and therefore you'd likely be writing custom software or paying a company for a professional solution. You can, for example, open two windows - your text editor on the left and a PDF preview on the right, giving the same effect as a WYSIWYG editor. GYI, groff is the same package that renders your manual ("man") pages on the command line.
Secondly, XML and XSLT. It's a couple of decades old, and a very verbose language, but you can produce some wonderful PDFs using this. The technology stack is heavier than groff (big binaries and dynamic link libraries), but it is very elegant in its own way. Also, instead of rendering to PDF, you could also take that XML document and render an HTML document.
Thirdly, use a PDF library. For example, if you're using C/C++, you could simply generate PDFs using libHaru. Other libraries exist for other programming languages. This would be a more verbose way of generating PDFs, and it also means that the report writers have to be famililar with whatever programming language you're using. This has pros and cons depending on your developers.
Fourthly, don't use PDF reports at all. Web pages can do pretty much anything. Why do you need PDFs? In my case, we need them, because our demographic is much older people that like print-outs.
Fifthy, use an HTML-to-PDF converter. One example is wkhtmltopdf. The "wk" stands for webkit, as that is the rendering engine in use. I believe this tool is slower that some of the other alternatives, but one of the great advantages is that the report developer only needs to know HTML.
Sixthly, use the CSS "print" media query. E.g., just like you can make "responsive" websites that change the look-and-feel depending on mobile vs desktop web browsing, so you can write a CSS stylesheet to change the look-and-feel of pages printed on paper. Like the above solution, this is a low-entry option.
In regards to business intelligence, I don't believe in Artificial Intelligence, or at least, not in the ability of a machine to learn anything that we did not teach it to learn. E.g., a piece of "intelligent" software can identify, e.g., big increases or decreases in sales, certain products changing in popularity, etc. However, it needs "organic" intelligence (i.e., a human) to draw together the factors involved, for example, that the increased sales were due to the lowering of the manufacturing cost that coincided in time with a big social media push. I'm just rambling now, but what I'm saying is that business intelligence is more than clever automated reports. You need to see data and trends (computers are good at menial jobs like counting) but software is nowhere near the ability to reason about cause-and-effect rationally, nor which effects are good vs bad.
In technology, we often talk about "black boxes". This is a great concept and is usually deterministic. That is, you feed in some input and receive some output, and if you feed the same input in 1000x times, you receive the same output 1000x times. With black boxes, the benefit is simplicity - you don't need to know how the internals work. This is based on the assumption that the black box works. If you feed the same input in 2x times and each time receive a slightly different output, this is not deterministic. If you feed in the report 1x and sometimes no output comes out (Java memory leaks, thread non-termination, etc), then this black box is faulty.
JasperReports is a faulty product. For anyone reading this, I cannot recommend strongly enough that you avoid JasperServer at all costs. Unfortunately, the place where I work has invested hundereds (maybe thousands) of hours developing dozens of reports. I can't count how many weeks we've spent investigating cryptic error messages like "unknown error, contact server administrator" or "Error closing context", with no trace of the referenced error messages in either the logs or the database. Usually a reboot and/or reinstallation works.
PLEASE READ THE OTHER FORUM POSTS ON THE JASPERSOFT WEBSITE - YOU'LL REALISE THAT THERE IS A SWATHE OF PEOPLE DISSATISFIED WITH THIS PRODUCT. AVOID AT ALL COSTS.
