: 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
- 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
- More primitives to define template.
- Adding primitives to the template definition tool make the system more
WYSIWYG and more powerful. Possible additions are:
- Colors are useful for high-lighting, just like fonts.
- Creating tables is usually very difficult in mark-up languages and any
help with this would be very useful.
- 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.
- 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
- Some good suggestions
- Good suggestions are always welcome and we will add them if they seem reasonable
(and not too hard to implement).