On Wed, 7 Jan 2004, Felix Breuer wrote:
Hello Inkscape Hackers!
I have a couple of questions:
In general: Does the planned plugin architechture of Inkscape allow for rendering plugins, i.e. plugins that render new/custom/other tags in the SVG document (embedded via the foreignObject tag)?
In general, yes we want it to have this capability, however I think it's probably a long way off. There's a lot of structural code changes in areas like style.cpp that need to be done before we can think of moving them to extensions. But putting some design thought into the requirements for it at this point would be very valuable.
More specifically: I would really like a MathML rendering plugin. Does your (planned) plugin architechture allow for such a thing?
If it does, my suggestion is the following: GtkMathView [1] is a very mature MathML rendering engine which provides a) a GTK rendering widget, b) a C++ interface for rendering MathML and, most importantly, a Bonobo component. For details see [1]. It might be possible to use this to render MathML formulas inside pictures/diagramms created with Inkscape without too much implementation effort (?).
Rationale: Currently there is no modern visual software to create mathematical/technical drawings. The free software user who needs such drawings (i.e. drawings that contain formulas) is forced to use programms like Xfig or to hand-code these drawings in LaTeX. Neither approach suits me and most of the mathematicians I know rather stick to pen and paper because of that. Hence, I think there is a not-too-small community of people who would be interested in this feature.
That sounds like something well suited to Inkscape. A number of people have been working on or are interested in seeing more technical-oriented features, and being able to display mathematical equations would be a very desireable feature.
If you think this is feasible with regard to Inkscape's plugin architechture, I might well take to the task of implementing the actual plugin. Please tell me what you think.
We're pretty early on in developing the extension architecture; it may not be fully usable until late 2004.
Here's a few options for you to consider:
1. Bypass the extension architecture and put it directly in the code. The boolean functionality serves as a good model for how this can be effectively handled - add your code in a subdir under inkscape/src/, and integrate it into the build system, then work in the hooks for using your code whereever they're needed. Submit it as a big patch for folks to test, integrate, and poke and prod.
If the code adds an unusual dependency, make sure to talk with some of the other developers first; we need to be careful that new dependencies are going to be widely available enough that people who don't need the feature won't be bothered by having to install extraneous dep's. A good rule of thumb is to look at what's available on redhat 7.3, OSX, and Win2k.
2. Help in developing the extension architecture. This will be of immense benefit to the project in general, but is the long road to getting MathML support. It's definitely the "right way" to go, but realize that we're starting essentially from scratch right now, so there's a lot of definition work to be done.
3. See if you can make use of one of the other extension mechanisms already implemented. For example, the stdin/stdout commandline scripting interface (see the roundhole script as an example). My guess is that it isn't going to be powerful enough for this case, but who knows.
So, if you have interest in developing the extension system, go that route, otherwise I recommend that you investigate feasibility of adding it directly to the codebase (for now). You can either submit a proposal for consideration, or go ahead and prepare a patch that does it and we can review and discuss it subsequently, depending on what you're most comfortable with.
Bryce