On Thursday 14 October 2004 14:59, Michael Reimpell wrote:
> My favourite notebook model would be a composition of:
> - XHTML with MathML for the classical document parts
> - messages to and from maxima (e.g. input, output, graphic objects)
> - some grouping elements for the document structure (analog to the section
> grouping of the macsyma notebooks)
>
This is very interesting. At first glance I would prefer XML with an XSLT
transformation to provide the XHTML as and when. This is because XHTML is
only strictly 'compatible' when keeping to pure XHTML.
Either way, it provides a serialised and portable view which offers obvious
significant benefits - not least of which is that the documents would
'upgrade' to later versions or new implementations without any difficulty.
> There is really no unnecessary wheel reinvention involved, since you can
> use existing DOM implementations for the model. Also, you can use existing
> browser views for the classical document parts, which can even be used to
> aggregate a view for the maxima messages. Other existing views (e.g.
> mathplotlib) may be utilized for maxima messages that are plots.
>
You're right, but there would be inherent limitations in the layout. As I see
it at the moment each item in the document would broadly need to be in a
vertical line below its predecessor - there would be no delicate placing of
text frames or pagination instructions for instance. Nevertheless, if users
were satisfied with the limits of an XHTML document layout (such as
printing/pagination not being fully controllable by the user) then it would
have big payoffs. I guess the XML master document could contain layout and
pagination hints for the main CAS GUI itself (whatever it was).
Thinking ahead a considerable time, it could even produce pdf files (fairly
straightforward in fact, on linux).
> For a first-time implementation in Qt, I would certainly simplify the
> above specification by using QTextEdit rich text for the classical
> document parts or even plain fix-font text. QDomDocument can still be used
> for the model. I would also implement very plain views, e.g. simply
> displaying the maxima interface language (1D-output in this case) without
> further formatting and using static images for plots. However, I would
> take care of the custom parts of the model (e.g., what is the model of a
> maxima plot?). I would also provide the possiblity to export the model to
> a maxima batch file, i.e. stripping output and putting the classical
> document parts into comments. This way, early adaptors won't loose their
> work regardless of future changes.
>
This does seem like a good way forward. I appreciate your suggestions. This
is exactly why I posted my first message asking for help.
> One thing that kept me from implementing this is the fact that there is no
> (documented) interface to a maxima server with a language that fulfills my
> requirements. I hope your development will directly and indirectly
> contribute towards such an interface. I wish you all the best!
>
Well I hope I can help as much as possible. Have you had time to browse the
code (the relevant file is engine.py) ? Do you have any suggestions (in
respect of the maxima server interface) that I could adhere to which would
increase future utility to yourself and other Maxima GUI developers? I am
currently discussing this same topic with another Maxima user who is using
PHP for the interface.
Taking this forward, I will round off the project as it stands, adding
matrices support, such that it is a useful tool to A-Level students and
casual users. I will then focus on serialising the document in the way
outlined here. Perhaps we could cooperate on a DTD for a Maxima document?
Regards
Abdulhaq