XSL:FO processing

I'm looking into using Formatting Objects lately for the MoneyJar project. Nothing is useful until it is possible to show the monetary amounts on an invoice for customers. :)

The problem here is again that there are many standards, each with pro's and cons, some of them much work to implement, others very easy but difficult to use for others... and the list goes on...

So I am doing some research in the area of XSL:FO and maybe write or extend another little editor around that. There is an editor on SourceForge called FAO, but I don't think it is very intuitive for people to use. I had lots of problems using it because I don't understand XSL:FO in the first place. Also, I don't think many other developers are willing to trawl through 400 pages of XSL:FO documentation in order to write a quick template for something.

XSL:FO is specifically created for the "printing" industry. I'm basically not doing anything else than rendering PDF at the moment based on a full "xsl:fo" document, but this final "xsl:fo" document is generated through an XSL-XML pipeline as well. So, the invoice generator I have set up prints itself in an XML format. This XML is forwarded towards the XSLT-engine, where it generates "xsl:fo". The final "xsl:fo" is then converted into PDF.

Yes, this costs processing power, but so does C + files + ASCII and the latter solution is much more error-prone. The best layout & printing capabilities of the latter is nothing compared to the powerful layout capabilities of XSL:FO + XSLT + XML, not to mention its portability to other document formats. Plus that if you have a printing press set up that accepts PDF to be printed and mailed into envelopes, there should be a solution out there that can automate this without the need to purchase an expensive package. So there you go, I'm sold!

So, if you know of a 'complete' editor for XSL:FO that does it all and is WYSIWYG and can be used to 'drag' element data or attributes into a view of some kind, that would be totally awesome :).

Money Jar

I've just released a new project on SourceForge. It is a financial library for Java with high precision. The target is to streamline the use of financial numbers in Java applications. BigDecimal supports the precise numbers. Surely, many people already use BigDecimal for finance, but issues like standard rounding and the currency the money is in are not resolved.

This library wraps BigDecimal into a Money class and has some features like automatic rounding based on JVM-wide configuration. It also does not allow calculations to take place between two incompatible currencies.

Since this project is more incremental, I intend to add more and more features to this library. The objective is to add "invoicing" support with some factories and helper classes, so that people can prepare invoices much easier. Another is to add a "tax engine", which is configured according to rounding rules, summation rules, tax application order, etc. to the nation/state where you live, so that taxes is much easier.

Researching about the subject of billing and taxation is a real head-ache. I do not intend to make this a library that you can use straight away in any part of the world. The configuration requires you to do the legal research, this library supports you in setting up the environment so that it is all resolved by itself.

I have some future plans a bigger project that uses this library that also involves some kind of distributed computing.

Open Source Progress

Together with some colleauges, I've written an article that was submitted to the Open Source Software Forum in Porto Alegre in April. We'll hear more if it was accepted 17/03.

The ideas are generated after thinking about corporate software use and licensing. The license costs in that area are huge.

The difference between corporate open-source vs. desktop open-source is that there is more "utility" for desktop opensource apps for any particular user and the user base is much larger.

Probably this is why there are so little corporate opensource projects available. I'm not talking about Apache webserver, Struts, JBoss or other projects. Those are platform projects. I'm more talking about specific solutions for specific companies, like CRM / HR / ERP / workflow etc. Yes, projects exist here and there, but the momentum behind them is very low.

So the idea was to generate an additional driver (money) behind opensource development, whilst keeping it open. We do this by proposing cooperatives that drive a system's development in cooperation with many other cooperatives across the globe. Ideologically speaking approaching an idea like syndication of some sorts and a main controlling body when the project gets out of hand.

We've analyzed the difference mostly from an economic perspective (the reason why anybody should even care or look into it, since opensource adoption by itself is hardly a goal). Next article we hope to present is more targeted at the specific composition and organization behind the cooperatives.