Extending Chart by external components

From Apache OpenOffice Wiki
Revision as of 08:27, 22 August 2007 by Bm@openoffice.org (Talk | contribs)

Jump to: navigation, search

Why not implement everything in OOo?

Intro: External Programs

Implementing all open issues directly into OOo will be both difficult and unnecessary. It is not always pertinent to reinvent the wheel and I will present later a better solution.

Disadvantages of doing everything in OOo

global disadvantages

  • many resources are needed (coders, persons to test the new features, financial constraints and time delays)
  • code becomes more and more complex, more difficult to understand by new developers, more testing time needed
  • most experienced coders work already on other open source projects; less availability for a new project

specific disadvantages

scripting (see later the asymptote program)

  • most of the current implementation has very limited scripting support
  • automation will therefore be difficult;
  • few users will develop new macros/ enhance the existing functionality of Chart because they will need to learn a new scripting language and/or OOo code

NO scripting means new functionality must be hardcoded into the Chart module

  • only users with advanced OOo knowledge will be able to do that


The main idea is:

  • to break the monolithic structure of Chart into various modules and
  • export the functionality into various external packages;
    • the new OXT extension architecture should ease this process;

A very good alternative is to do all advanced things with dedicated external software, when such free alternatives exist. Below are listed some existing programs suitable for this task: (see also Links section below)

    • gnuplot: powerful scientific package
    • asymptote: powerful scripting capabilities
      • powerful descriptive vector graphics language for technical drawing
    • R (with over 500 packages):
      • extensive data visualization capabilities: see examples below for details;
      • also ideal for scripting;
    • ggobi: data visualisation system for exploring high-dimensional data
      • see also the R-package rggobi
    • YALE: a data mining application
      • for specialized data visualization techniques, see the screenshots;
      • examples include: 2D and 3D scatter plots, the Self-Organising Maps (SOM) and many other advanced techniques
    • octave: a high level mathematical language
    • various other packages, e.g. FreeMind and many more, each suitable for some specific task.


  • New Features: once the external program is embedded into OOo, one can easily implement many new features (from the specific program) with minimal effort (see also Automation)
  • Advanced Solutions: dedicated programs offer more advanced solutions than any OOo implementation (or even that of competitive software)
  • Resources:
    • less resources needed
    • programs are developed by their own groups,
    • tested by appropriate folks (mostly proffesionals) and therefore
    • NO major delays and less propensity for bugs
    • new features are implemented more easily (we at OOo need only make a new Menu/Gui and paste the correct syntax/call to the external program)
  • CODE: smaller code, smaller program
    • only users that need that option will run it (or download it; see also the note below)
    • most other users will not have it installed, therefore OOo should also run faster; not so many resources loaded
  • Automation:
    • some of these programs come with very powerful scripting capabilities, e.g. gnuplot, asymptote, R-software
    • the previous programs are used by millions of users, many of whom already know the scripting/ programming language, and therefore do NOT need to learn a new language (see downloads on sourceforge.net for the first 2 programs)
    • easy creation of new macros/scripts; no need to hardcode new functionality into OOo

Another strong reason why external software is a better alternative:

If the coders aren't working with people that know how to do numerical methods
then what are the odds that it'll even come out correctly [quote from a user]

A special note:

  • because some licenses may not be compatible with OOo (although they are still open source), I DO NOT MEAN to include the code in OOo
  • what I mean is a general mechanism in place that allows OOo to communicate (bidirectioanly) with the external software
  • instruct users what external programs (extensions) do exist and where to find them (provide url)
  • allow users to easily access the functionality of external programs through OOo Menus (or functions)


  • Clearly the biggest disadvantage is compatibility. You cannot replace the chart module of OOo, because you need it for old files, for macros and extensions using the chart's UNO API. Therefore, this can only be an addition to the chart module.
  • External program may not run on every platform OOo supports
  • Licensing of external programs may be different
  • You depend on the other software. As nice as it is to get new features and bug-fixes for free, when you need something urgently it may be difficult to get. Even when it is open-source, it may not be so easy to get familiar with the code. Also, you still depend on other people that decide whether to include the changes or not, unless you do a fork, which is mostly unwise.


see also:

External Software

External Chart Types examples

Personal tools