MathSpad : Future Features.

Like every large program, MathSpad is never finished and there will always be someone who is missing a feature, would like to see something changed or finds an unknown bug. This page contains some of the features we are planning to add. If you send suggestions and wishes, we can add them to this list.
Interface to other programs and mark-up languages.
Although you can already generate almost any mark-up language, programming language or program interface language, MathSpad is still heavily based LaTeX and it is sometimes difficult to work around that. We will solve this by allowing multiple output formats for the same template, a configurable window layout and a better keyboard interface.
Better keyboard definitions
It is possible to change the keyboard definitions in the current version, but it is cumbersome and features like variables and argument passing are missing or limited. Defining shortcuts for symbols and templates is possible, but an easy interface to define them is not available yet.
More stencils
It is much easier to use MathSpad if a stencil for your ``language'' is already available. Like LaTeX, you are not going to use the system if you have to write the macro packages yourself.
More primitives to define template.
Adding primitives to the template definition tool make the system more WYSIWYG and more powerful. Possible additions are:
Colors
Colors are useful for high-lighting, just like fonts.
Tables
Creating tables is usually very difficult in mark-up languages and any help with this would be very useful.
Images
Displaying included images would be helpful to get an indication how it will look in the final output.
Some programming facilities
It would be useful if you have more control over the output. A construction like: ``[if outputmode = HTML then <B> else \bfseries fi]'' would be helpful if you want to generate both HTML and LaTeX with the same template.
Optional arguments
All mark-up language have constructions with optional argument. In HTML, the image tag has a lot of options which are not alway used. Instead of defining multiple version, you could use the construction [opt ALT="alt" tpo], which would only produce output if the argument alt is not empty.
Actions
A template could define an action to be carried out if that template is selected. Possible actions could be to start a program to edit an image, open a document with a given name or move to the position where a certain label is defined.
Short cuts for templates
A template could contain the keyboard short cut for that template in its definition. Load a set of template will adjust the keyboard short cuts for that set.
Support for internationalisation
By default, MathSpad uses the ISO8859-1 encoding for normal text, but you can change this to any other encoding, including a two-byte encoding like Unicode. By making Unicode the default internal encoding, encoding conversion should be easy and MathSpad would be usable world wide.
Configurable window layout (localisation)
Different mark-up languages and different people use different functions. To keep the layout compact and to the point, a user (system manager) should be able to adjust the layout to remove certain functions, to add others or to rename or translate them. Especially if you are testing interfaces to different back-end programs, it will be very useful if you don't have to reinstall the program.
More symbols
Although the default set of symbols is rather large, more symbols should be added. There should also be an easy interface to add your own symbols.
Document Conversion
A conversion tool will enable you to convert existing documents in the output format to the representation used by MathSpad. This tool will generate parsers from the templates that could be used to produce these documents. An alpha version of this tool is available in the current distribution and can be turned on with the compiler option -DPARSER.
Some good suggestions
Good suggestions are always welcome and we will add them if they seem reasonable (and not too hard to implement).