Hi Leonard,
Leonard Mada wrote:
Hi Bjoern,
Bjoern Milcke wrote:
Hi Leonard,
I think I still do not quite understand what you want, apart from
plugging R into OOo,...
I want an abstraction layer to the UNO Classes, and an interpreter that
reads simple commands like plot(), draw() and accesses the corresponding
UNO/C++ classes to create than the objects.
The problem with scripted charts is that usually the generated charts
can not be changed interactively via a GUI
This is not true:
- the objects would still be in the end constructed by the various low
level chart subroutines/classes
- and these low-level classes could have methods (as they surely already
have) to change them interactively;
The advantage of my concept is, that me (and many others) can sit down
and implement new types of charts without having any idea about UNO
components. There is the abstraction layer, that does this job. This is
the reason why R, gnuplot and alike are so popular in the scientific
community. And the OOo team does not need to spend all their time with
implementing new chart types. The community will do this.
Let's give an example - a Venn diagram - this is constructed using
Asymptote:
size(5cm,0);
pen colour1=red;
pen colour2=green;
pair z0=(0,0); // COULD TAKE SOME VARIABLES FROM THE SPREADSHEET
pair z1=(-1,0);
pair z2=(1,0);
real r=1.5;
guide c1=circle(z1,r);
guide c2=circle(z2,r);
fill(c1,colour1);
fill(c2,colour2);
picture intersection=new picture;
fill(intersection,c1,colour1+colour2);
clip(intersection,c2);
add(intersection);
draw(c1);
draw(c2);
And I could easily replace a circle with a triangle or make any other
change. I can customize every aspect of this diagram, which is not
possible if it is hardcoded into OOo. And everybody (not only the OOo
gurus) understands that draw() must draw something and fill() will
probably make a fill.
Now what should the Chart module do:
- it should take this high level graphical commands and interpret them
using low level OOo objects/ UNO classes/ whatsoever.
- the graph should be stored in the file/document using xml that maps
directly to the low level commands
- if the user wants to customize the graph, build low level methods
(this is actually the case even now), do not change the script
- ... then the script wouldn't match what the final output is: while
true, this has no relevance, as the script is used only to create the
chart initially (as a wrapper for the complex low level commands) and to
allow for the greatest flexibility doing this
When the diagram is resized now by the user afterwards. How should the
low level shapes that were created by script now be replaced and
resized? You might want to strech a bar but you might don't want your
symmetric symbol be stretched. Low level shapes don't know anything
about coordinate systems. So with this simlpe approach the diagram would
look like rubbish after the first resize.
Thanks,
Ingrid
Kind regards,
Leonard Mada
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
