opentag-presenter on GitHub »

A Simplified 2-D Renderer

Approaching the Problem

<OpenTag>Presenter required an engine to display two-dimensional objects. Since literature on the subject couldn't be found, it was decided to base the display design on the most common 2-D viewers used today - web browsers.

Microsoft PowerPoint enforces a width:height ratio for presentations, with different zoom levels available for viewing. However, I faced more limitations using the Qt toolkit. While the library supports different font sizes, the width:height ratio of text isn't always the same at different font heights. This means a presentation displayed at one zoom level may not show correct at another zoom level.

Also, PowerPoint assumes the user will be viewing presentations at that set width:height ratio. I wished to have <OpenTag>Presenter be able to view presentations at any display dimensions a user wishes. Hence, it was chosen to emulate the object alignment algorithms of web browsers. Objects would be drawn relative to each other from left to right. This could easily be represented in XML with the code ending up almost identical to HTML.

Object Alignment

Objects in a presentation slide are displayed sequentially. By prototyping a renderer design, I decided a simple solution for aligning objects would be to start from (x, y) coordinate (0, 0), passing it to the first object to to display, which would draw the object and then return the (x, y) where the next object can be displayed.

For instance, a slide containing only one image with the margin set at 32 pixels would start rendering at (32, 32), pass those arguments to the image object which would display the image with it's top left coordinate (32, 32), then return (x, y) where another object can be drawn. The returned (x, y) would be (32 + image width + padding, y that was passed as an argument before). The padding would be needed so text and other objects aren't drawn up to the right side of the image, causing a cluttered looking presentation.

render cursor example

(32, 32) would be passed to the image and it would return (32 + image width + padding, 32). At the returned coordinate, another object could be drawn by passing these arguments to the next object. This series of coordinates travels across the display aligning objects - which I coined the render cursor. Just as a blinking bar that moves on my monitor as a type, the render cursor moves through the display as objects are displayed as it guides the objects to their coordinates.

Objects are drawn left to right and when a sequence of objects go past the right margin, there would be a line break, where the last object would be drawn below the current sequence of objects which form a horizontal line. A line break would be skipping the height of the highest object on the current line and then skipping the number of pixels needed for the line spacing set by the user.

Text Handling

Blocks of text are split up into words. These words are then displayed across the screen and a line break is made once the words reach the right margin. Text can be preformatted (ala the HTML <pre>), but otherwise newlines and tabs are ignored, which eliminates worry about the formatting of XML code. I wanted to accomplish the freedom of HTML.


Objects in the display can also be animated. However, given the tools, only primitive animation techniques can be used, such as scrolling an image or equation across the screen onto the place where it was decided to be rendered. If an object has its animation property set, it is simply hidden until the user chooses to animate it, at which time the proper algorithm takes over to move the object around the display until it reaches its final destination. Speed and delay properties are available to control the amount of time it takes for the object to reach its destination (which is processor speed dependent).

Limitations of the Implementation

The Obvious Problem

What it all comes down to is that the 2-D renderer design adds too much complexity to extensions written by other users. The basis of the whole system is that it's open to modification, unlike closed projects such as Microsoft PowerPoint. More simplicity is needed as the current design is counter-intuitive. The rendering portion of the system must be extracted from the object definition portion.