GeometryEditor: An SVG-based Interactive Geometry System

Table of Contents

Interactive Geometry Software
Web-based Interactive Geometry Authoring System
Overview of GeometryEditor
Architecture of GeometryEditor
GeometryEditor Authoring Environment
GeometryEditor and SVG
GUI Implementation and History with SVG
SVG for Geometric Object Rendering
Scripting and Page Authoring
Scripting a construction
Page Authoring

Fundamental principle of Interactive Geometry Software is: geometric objects of a construction maintain their mathematical relations under mouse operations or driving data changes.

Figure below shows a construction of the circumcircle of a triangle. Manipulation of any vertex in the construction will cause the circumcircle to be updated accordingly.

Google Docs vs. Microsoft Office is a typical comparison between Web-based system and traditional desktop-based system.

We can easily list some desirable features a Web-based Interactive Geometry authoring system should have.

  • No software installation

  • Fast loading and fast initialization. If it takes to much time to load, there is no advantages over desktop-based systems. Almost any systems using Java technology partially fail this condition ths first time they run.

  • Fast interaction response. Interactive Geometry Systems are computation intensive, and interaction intensive. The performance of a Web-based system should be almost as good as a desktop application.

  • A geometry construction is saved on the server side, and can be created, accessed, and modified from anywhere.

  • Easy publishing and sharing.

  • Easy searching for useful constructions

  • Scripting support to allow interaction between the construction and the enclosing HTML page. We don't want a construction in a page to be an isolated part. We want to retrieve data from within the construction or drive the construction by contents in the enclosing page.

HTML/SVG/JavaScript together are an ideal environment to meet the above requirements.

While the engine provides the core functionalities for GeometryEditor, the GUI makes user control simple and intuitive, an important requirement especially for teaching and learning.

Since GeometryEditor runs in a browser, its GUI depends on the widgets made available by the browser to a Web page.

At the early development of GeometryEditor, the GUI implementation was greatly affected and limited by the browsers’ SVG capability.

In 2004, the only way to view SVG was to use Adobe SVG Viewer plugin to work with browsers on Windows, Linux and Mac. The problem was that except on Windows IE, the plugin lacked the ability to communicate with the enclosing HTML. I had to develop menus, toolbars and dialogs all in SVG. And the GUI communication with the GeoSite had to be implemented using Adobe SVG Viewer’s getURL/postURL , which was a non-standard extension for SVG.

In May 2005, Mozilla Foundation released Firefox 1.5 Alpha, which is the first browser to have native support for SVG. The SVG-HTML cross communication problem is gone. Standard Ajax technique can be used instead of plugin’s non-standard extension. Furthermore, With Firefox, we can also utilize widgets made available in XUL (XML-based User Interface Language) including different menus, listboxes, trees, and tabboxes. Further, our GUI implementation uses XBL (Extensible Binding Language) for creating user-defined widgets. I started to migrate the GUI of GeometryEditor using Firefox’s XUL and XBL technology.

In 2007, Opera 9 started to support SVG natively, and so did Safari 3.1 in March 2008. SVG was well accepted and adopted by major browsers except only Microsoft Internet Explorer. In order to make GeometryEditor be compatible with Safari and Opera, I started to use HTML/CSS to develop the GUI.

The GUI works closely with the Geometry Engine. Some GUI widgets need users to select objects from the canvas controlled by the Geometry Engine. Some GUI widgets activate some actions or events in the Geometry Engine.