Yesterday was pictured an idea suggesting something was coming.

So, here it is :


the results of xlsgen 3.5 chart rendering engine

So why our own built-in chart rendering engine ?

Key motivations :
- Native 64-bit rendering scenarios
- Trivial deployment : no more Microsoft OWC (Office Web Components) deployment / registration
- Print scenarios
- Comprehensive (all chart types, all chart formattings)
- Fast
- Excel XLS and XLSX compatible
- No more third-party dependency (particularly Microsoft OWC component, which is not supported anymore)

When chart rendering was introduced in xlsgen with version 2.5, the reliance over Microsoft OWC
charting component was an obvious choice given that this component was free to use, originating from
the Microsoft Office team, and versatile enough to accomodate a number of core scenarios.

But as time went by, while xlsgen refined the integration of Microsoft OWC charting component more and
more with every release, two major obstacles made their way : 64-bit on the one hand ; Microsoft hotfixes
and kill-switch related to Microsoft OWC on the other hand.

The 64-bit obstacle was unfortunate. 64-bit happened and Microsoft chose to never release a 64-bit
version of their OWC charting component. So for 64-bit scenarios, xlsgen could not render charts. It could
read and write charts from XLS and XLSX charts, but it could not render them in print, preview, PDF, ...,
scenarios. This became a major problem for our customers when two years ago organizations out there
started moving to Windows 7 64-bit, basically 64-bit on every desktop or server.

This problem became worse over time as Windows 7 proved to be more touchy about doing simple things such
as registering COM components or even running a COM component at all as we have learned. So when we told
our customers that they could run 32-bit scenarios on 64-bit systems, which was and is still true to this
day, it forgets to take into account all the configuration work that has to occur on customers PCs to get
such a simple scenario to work.

We had to come up with a better solution for this because from the beginning one of the tenets of xlsgen
was to always provide a run-time environment that meets the environment of customers, not have our own
customers adapt to us.

After months of work, we are happy to announce that we have engineered a full chart rendering engine from
scratch and can now render charts no matter the system you are using. Obviously, you can still use
Microsoft OWC chart rendering if strict version compatibility is a key feature for you. One line of code for
making the compatibility scenario up and running is all it takes. By default, beginning with xlsgen 3.5, our
built-in chart rendering engine draws all charts where chart rendering is involved, i.e.
print, preview, PDF, XPS, HTML and extract scenarios.

The other obstacle was Microsoft policy for hotfixes, patches and ActiveX kill-switches. To add insult to injury,
Microsoft chose to provide their customers with disabling tools as opposed to fixing security problems in their
own software, for instance vulnerabilities found in Microsoft OWC charting component over the last few years. By
doing that, customers killed the very idea of using Microsoft OWC charting component either directly or through
xlsgen. Combined with the move to 64-bit, it explains the urgency for us to come up with a working solution
for Microsoft "legacy" support problems. Giving way to our own chart rendering engine.