Mnemonic Mnemonic: the big picture
General Info

Introduction
Screenshots
Mailing Lists and IRC
Alternative Browsers
Special Thanks

FAQ
Understanding Mnemonic
TODO list and ideas
Bug Reports


User Info

Download binaries
Platforms
Compiling Mnemonic
Other useful software


Developer Info

Core
Message modules
Library modules
Object modules
Coding Guidelines
Browse Source
Using CVS


View with any browser

Website questions to:
webmaster@mnemonic.org

Mnemonic questions to:
disc@mnemonic.org

 

The big picture

This page and the accompanying technical one give an overview, at two levels, of the mnemonic project. The first few sections describe the `modern' view of the web, by which we mean the web based on XML and CSS rather than fixed HTML. After that, the structure of mnemonic itself is discussed. We explain how the modules of mnemonic interact with each other.

The text on these pages is not intended for the absolute beginner. You might want to have a look at CSS tutorial by John Allsopp if you want to learn about CSS. Or at one of the various texts on the w3.org site if you are interested in understanding XML or any of the other new standards. An extremely large number of links to XML resources plus a readable overview of what the hype is all about is available on the Oasis SGML/XML web page.

A modern view of the web

In the world of HTML, elements in a document have both a fixed meaning and a fixed display characteristic. For example, children of a <H1> element are meant to be `the text of a header', but they are also supposed to be `rendered in a bigger font'. Or take <BR>, which indicates the end of a continous section of text, but is also required to result in a fixed behaviour on-screen, namely a start of subsequent text on a new line.

This changes with XML and CSS. An XML document can have tags with any name you like, because the names of the tags do not say anything about how they should be rendered on the screen. Instead, that information is stored in a separate file, the CSS file. In this file, you can state that the text that appears in the <RECIPE> element in your XML file should be rendered in a red box with a blue border, for example.

Unfortunately, the above is not really true. CSS only has keywords to describe the visual characteristics that we have known from HTML (plus a few more). If you want to encode eg. vector graphics in an XML file, or write your chemical formulae in XML, there is no way to describe, using only CSS, how the content should be displayed. The same is true for mathematics typesetting.

Rendering engines will in general therefore need to know two things about a specific subtree before they can decide whether they are able to display it: the XML namespace in which the subtree resides and the stylesheet information associated to it.

This immediately leads to questions such as `how can an arbitrary XML file (in a non-standard namespace) inform the renderers that there is no rendering information beyond that provided in the CSS stylesheet'? These sort of questions have been ignored by w3.org. In mnemonic, the renderers which do handle a specific namespace will have priority over those that don't. In this way, all documents in namespaces for which renderes are available are rendered correctly, while the others will be rendered in a `best approximation' using the CSS display properties.

On ``content'' and ``presentation''

Unfortunately, the distinction between ``content'' and ``presentation'' as emphasised by the introduction of stylesheets has not been pushed to the limits far enough to make it really clean. As discussed in the previous section, several elements in HTML, and most elements in new applications of XML, like MathML or SVG, do not only describe content but also some aspect of presentation. As an example, the &;SUB> tag in MathML is supposed to be rendered as a small subscript. This has nothing to do with content. Instead, there should be a default MathML stylesheet which encodes that <SUB> elements should have the ``vertical-align'' property set to ``sub''. Similar (or even better) examples can be found in SVG.

Put in a different way, one could say that even with the introduction of stylesheets, XML application descriptions describe the visual properties of tags, whereas this should be done in an extension of the stylesheet language. The section ``presentation markup'' in the MathML specification, while very important, does not belong there. Instead, the MathML specification should have been written in two parts: ``MathML content tags'' and ``MathML stylesheet extensions''. The first part describes a convention (ie. which things are important to distinguish in a mathematical expression, and what names should we use for them) which the second part describes new rendering requirements. It's of course a pity that the combined forces of the zillions of parties associated to w3.org couldn't figure this out, but unfortunately it's to late to change that now.

Still, Mnemonic tries to make the best of it and separates content from presentation as much as possible. This means, concretely, that there is no fixed coding for the rendering of HTML elements, except for a very small number of exceptions (like the <A> tag, which has to be presented as a clickable link). Almost all of the presentation is based on a default stylesheet for HTML, and the renderer uses that stylesheet information to determine the presentation, unaware of the (historical) meaning attached to the particular element names.

The Mnemonic approach to modularity

(text below is from mozilla discussion, but mnemonic does exactly this). For example, consider an XHTML document with "foobar" markup included inline:

<html xmlns="http://www.w3.org/TR/xhtml1">
  <head>
    <title>foobar in XHTML</title>
  </head>
  <body>
    <p>Some foobar markup:</p>
    <foobar xmlns="http://some.where.com/foobar">
      <foo>content</foo>
      <bar>content</bar>
    </foobar>
  </body>
</html>
If I have the foobar module, this just works--no window borders for a plug-in box, foobar content display is not confined to any particular place in the document display, and foobar content display can overlap XHTML content display and make sensible use of full or partial transparency.

How document elements get rendered

As explained above, modules announce the availability of new data by broadcasting messages. When another module is interested in the data, it will accept this message and thereby inform the sender that it can continue to send data of that particular type.

For rendering of documents, this means the following. The output of the parser (for html documents, this will be a DOM tree) is announced using a message. The same is true for the output of style information (eg. a CSS stylesheet). A rendering engine that knows how to display css styled data can accept these messages. In turn, the renderer will announce the availability of the layout tree it creates by sending another message.

At some location in the tree, there might be elements (eg. <math> or <img>) which the present renderer cannot handle. The renderer can then send an announcement message informing the system that this new subtree is available. It will also register an interest in possible output that can be merged back into the layout tree. A module that is able to turn this particular subtree into the layout tree of this particular type will now take over.

For all renderes, there is a library of basic box types in lib-[type]layout. This is the way to communicate layout structures to other parts of the system. In particular, we have

  • mnemonic-oil-gtkw3render
  • mnemonic-oil-gtkmathrender
  • mnemonic-oil-gtkvrmlrender
  • mnemonic-oil-psw3render
  • mnemonic-oil-psmathrender