SVG: A Key Element in Achieving Product Differentiation and Competitive Advantage in the DVB Market


In the increasingly crowded and competitive digital receiver marketplace, the ability to create branded, differentiated products is critical for manufacturers to attain market advantage. One of the most effective ways to achieve this level of differentiation is through the development of User Interfaces (UIs) which can differ throughout the product line and across multiple regions. However, the UI development process is often fraught with difficulty. Traditional development techniques often make it extremely difficult to develop, simulate and test new interfaces to the levels of robustness required at the speed the digital receiver market requires. Implementing a new graphical design for a new or legacy application demands a critical amount of precious engineering resource both for development and testing.

In order to support manufacturers who need to create differentiated UIs within short product development timescales, Cabot Communications have developed a SVG processing module that interacts with Cabot’s more traditional C++ based UI Framework. The features of the SVG processing module enable visual UI changes to be made by graphical designers instead of software engineers, effectively freeing up precious engineering resources. SVG provides a mechanism that is reusable and requires less engineering resource for any future UI iterations, negating the need for reprogramming for differentiated UIs, and allowing mission critical robust functionality to be maintained in C++.

The development of a SVG support module enables the implementation of skinnable applications, where the definition of the look and feel of the UI has been separated from the application code. This provides a mechanism which allows the UI to be designed independently and for production engineers to use and deploy the new design very quickly; as it enables only the completeness and usability of the new look and feel to be tested, independently of existing underlying product functionality.

The SVG processing module liberates design creativity by enabling esthetic graphical drawings defined by SVG instead of the traditional method which could only accept small images suitable for embedded systems. With SVG, manufacturers are able to provide new UI designs and their SVG definitions so that they can be easily integrated to applications with minimal time and effort. In addition, SVG enables graphical designers to easily see how their design looks on the resultant application through Cabot’s dynamic PC based SVG simulator which provides an instant UI visualization, allowing greater experimentation.

Cabot has developed a SVG engine that processes a subset of SVG Profile Basic 1.1. The SVG elements that are supported by our SVG engine are line, rectangle, circle, ellipse, polygon, polyline, path and linked images. In DVB UIs, we commonly need widgets, such as buttons, text boxes, selection boxes, list boxes, scrollbars, etc. We have also developed C++ widget classes that can process and use the graphical designs defined by SVG.

Each skinnable UI dialog and widget type has corresponding SVG files that describe their graphical, scallable, and positional aspects for each state that they may be in. Hence a SVG file describing a dialog is a template, containing the background visual appearance and the size and position of any widgets or optional elements. Simple id fields are used to identify SVG elements to the C++ implementation, where the application functionality resides.

To summarise, we feel that SVG provides our customers with a number of competitive advantages:

• Flexibility: Commercial graphical tools support SVG for complete flexibility in creating customised UIs

• Efficiency: SVG enables UIs to be easily created and modified without the constraints of traditional UI development tools which require engineering time and effort. In addition, greater re-use is encouraged.

• Quality: The perceived quality of the UI is greatly enhanced when graphical design experts are used

• Liberates existing applications: Tested legacy applications can be deployed to different customers with ease.

• Hardware independence: The entire application can be developed within a PC environment before being moved to the receiver hardware

• Complete UI reassurance: Enhanced SVG features dramatically reduce the possibility of UI problems once the product has been deployed, resulting in optimal consumer satisfaction and reduced support calls and product returns

• Cost effective: The benefits delivered by SVG enable manufacturers to reduce the development costs and engineering effort required to make differentiated UIs

• Increased speed to market: The features provided by SVG enable customised UIs to be built, simulated and tested in previously unachievable time scales

Cabot’s future plans include extending our SVG processing module to include more SVG features, in order to enable designers to develop even more compelling UIs.

Table of Contents

Cabot Background
Historical Cabot Software Architecture
 Problems to be Solved
Simple SVG Solutions
Cabot Implementation
Practical Case
Future Development

Embedded device solutions are intrinsically associated with systems with little resources.  Cabot’s modular C++ based software stack has been designed to overcome resource constrained environments and to provide highly portable, compact and efficient solutions for all DVB applications.  Over the years, Cabot software has been successfully deployed on over 15 different chipsets.

Whilst the C++ language has many clear development advantages, the implementations and operating systems provided by silicon vendors do not always provide the facilities developers have become accustomed to.  For example, C++ template and exception support is not always available.

Initially, Cabot developed a C++ UI Framework based on concepts similar to that used by MFC (Microsoft Foundation Class [2]) in which to develop customer applications. This framework provides a set of fixed graphical styles and developers use a proprietary format resource file, compiled into C++ using Python, to define the look of an application.  Any deviation from the predefined graphical styles must be coded in C++ by the developer using simple graphical primitives provided by the UI Framework. Widget positioning itself must be coded in C++ for each dialog.

The Cabot UI Framework proved successful in delivering robust and feature rich applications, however the nature of the MFC-like framework has lead to the look and functionality of such applications being highly coupled.

The proprietary nature and fixed styles provided by Cabot’s UI framework has lead to the visual appearance of implemented applications being quite similar. Whilst the C++ nature of the UI framework itself allows the implementation of almost any graphical treatment; limited engineering resource and time to market pressures have meant that graphical changes attempted by customers are basic. Typically this is limited to colour changes and simple use of the fixed graphical styles provided by the proprietary resource compiler, for example adding a rounded border to buttons.

The traditional Cabot UI Framework does not integrate with any third party tools, leaving an impenetrable barrier between the designer and developer. In all cases the designer must deliver mock up user interfaces and the developer must realise these interfaces in the C++ code. This is neither useful for the developer nor designer; the designer is not free to experiment with the limitations of the software and platform; and the developer must carry out painstaking tasks to ensure that the layout is correct, costing valuable engineering resource.

Many third party solutions providing embedded systems’ user interfaces exist in the marketplace. Whilst such solutions provide feature rich authoring tools, the tools themselves are more often proprietary and have small user bases. As such,  extensive training and support needs to be provided by the tool vendor for both authoring and porting software libraries. This type of model is most suitable for large design houses or CE manufacturers that can commit their design departments to familiarising themselves with such technology. As a middleware vendor Cabot must provide a solution for all of its customers.

Furthermore, third party solutions incur either a third party royalty and/or high tool cost, which would prevent Cabot from providing the most cost effective solution to its customers. Today's high end products will undoubtedly become tomorrow’s low end products, and as such are likely to become more price sensitive over time.

The success of Cabot’s UI Framework means that right now there are many feature rich robustly tested applications already deployed in the marketplace. Much engineering effort has been invested, and many customers rely on the intellectual property contained within applications. A feature rich, robust DTR [3] application can take over two man years to develop. Developing an entire application in a new language would mean disposing of existing code and committing more development resource, a difficult decision to make. As a result, Cabot decided that it needed a technology that would liberate its applications, or at least provide a path to a better future.

SVG provided Cabot with the perfect technology to experiment with; as an open standard there are many resources and tools available; and as an XML based technology it is easy to manipulate in almost any language. In addition, it was clear that a SVG based solution could preserve existing robustly tested C++ functionality contained in legacy applications.

One of the key considerations was to keep the SVG side simple enough for designers to use, yet flexible enough to enable them to explore creative possibilities.

From the UI Framework perspective this meant mirroring the existing widget set and concepts for Cabot’s highly skilled C++ developer base. For the designer we decided not to extend the syntax or include any of the scripting facilities possible. Furthermore, the debugging facilities must always be an important consideration in developing real time applications. Complex debugging would be carried out by C++ engineers, so duplicating debugging environments should be avoided and debugging facilities kept in the C++ domain. In addition, performance and code size must always be a consideration in embedded systems, implementing scripting and DOM models completely would most likely impact such areas.

This “keep it simple” approach would help focus the development and reduce future support costs, at least for the initial implementation of SVG with Cabot software.

Basing an initial implementation on Cabot’s UI Framework would constrain the graphics capabilities to that of the existing rendering engine. Only basic graphics primitives are provided and the palette is constrained to 256 unique colours. However, existing powerful internationalisation features could also be used as is.

The ability to enable designers to develop content interactively, with real DVB software, is an important aspect of the solution for Cabot. The Cabot Observatory product provides a real implementation of the Cabot stack on a PC. Integrating the SVG solution with Observatory would allow UI designers to interactively produce content, understand the SVG implementation, and see exactly how the rendering on the final platform would look. Most importantly it would allow designers to explore the creative process in a new way.

Traditionally, graphical resources and dialog layout in Cabot applications had been locked into the implementation. User interfaces described in SVG offer the opportunity to be used more readily in future technology, whether this involves being manipulated to another format using a tool or allowing software to be easily developed to read the resources directly themselves.

The Cabot stack has an existing rendering engine used for its Mercator MHEG implementation ([4], [5]) and its UI framework. A simple SVG renderer was built on top of the facilities provided by this engine within the UI Framework. Use of the existing engine constrained what could be implemented in SVG, but provided a working subset of the features required to make SVG useful and reduce development time. Support was provided for lines, polygons, circles, ellipses, paths, and linked PNG files; using a 256 colour model within a standard DVB screen resolution of 720x576.

Efforts were made to abstract the engine away from the proprietary concepts of the existing UI framework. Interfaces were put in place to provide mapping to the palette, image, and font resources that would be used to support SVG rendering. A drawing façade interface allowed the underlying Cabot rendering engine to be driven without coupling the implementation.

In order to facilitate the widest possible use of SVG tools, keeping the designers task firmly in mind, and best serve our C++ developer base, we decided not to extend the XML syntax used. The principle was to “keep it simple” as much as possible, at least for this first implementation of SVG technology by Cabot. To this end, only 'id' attributes were used to integrate with Cabot applications. The 'id' attribute provides a simple mechanism for identifying the position and size of SVG elements, and can be used to bind the SVG to the C++ concepts at runtime. All SVG tools support the manipulation of the id attribute, and it is an easy concept to communicate to users. Naming conventions allow these SVG elements and their properties to be used in the C++ software. The simple Cabot renderer fills a collection of “named rectangle” shapes, those shapes with an id attribute, whilst performing its rendering task. These “named rectangle” shapes are not rendered, but available for the C++ code to interrogate their properties.

Rather than embed all the SVG required to render a dialog, sets of SVG files would be developed associated with a group of widgets. SVG files are referred to in the C++ code to bind the SVG elements at runtime. This provides a clear and relatively flat interface for designers and developers to work with. The Cabot DTR application itself consists of over 70 dialogs and menus, represented by 150 separate SVG files.

The next task was to develop a widget set. Our requirement focused on the need to make it easy to port existing UI Framework applications. The UI framework gave us a ready made widget set to act as a basis for implementation. The widget set includes:

  • TextBox

  • Button

  • SelectionBox

  • ListBox

  • Progressbar

  • Scrollbar

  • Menu

  • TextEntryBox

The UI framework widgets have a simple focused or unfocused state. This model was adequate when the UI framework was developed but since then applications have grown more complex. The SVG implementation extended this focused/unfocused model, to give the designer more flexibility with the graphical styles. Each widget in the SVG implementation can have one of four widget states:

  • Focused Active – the widget is selected, the user has “highlighted” the widget, key presses act on this widget

  • Unfocused Active – the widget is not selected, but the user can use key presses to “highlight” the widget, key presses may navigate to the widget

  • Focused Inactive – the widget is displayed but cannot be used, but was previously “highlighted”

  • Unfocused Inactive – the widget is displayed but cannot be used, but it was previously not “highlighted”

The transitions between these states are shown in the state model below. This state model is driven by the C++ framework in which the widget set is implemented.

When a widget is rendered as part of a dialog, a discovery mechanism finds the SVG files associated with each state. Within each of these SVG files there are groups of graphical elements that allow the software to resize each widget to the required size. The widget requests the rendering of each group at the required position, providing an appropriate scaling transform for each group.

For example, a button widget has a default SVG file “buttonFA.svg” that provides the look of the widget when it is in a focused active state. The SVG contains three groups, each group has a name and describes a part of the button - the left end, middle, and right end.

Simple button widgets only require three groups, and as such they can only be scaled horizontally. The diagram above shows the naming convention given to the groups in the SVG file itself. When the button is rendered the groups “gRowL” and “gRowR” are rendered at the end of the available space without any scaling. The “gRowM” group is scaled horizontally when it is rendered to fill the space in between “gRowL” and “gRowR”.

Rather than use SVG 'mask' elements to facilitate the exact positioning and scaling of the graphical elements within each of these groups, our renderer allows graphical elements to be scaled and rendered relative to named rectangles described earlier. Using this concept rather than masks makes the implementation of the SVG renderer much simpler, and allows the position of such masks to be identified more clearly in graphics tools.

The overall structure of the SVG file for a button looks like this:

A button SVG file has one more important element, an indication of the position and attributes of the text that renders the button label. We use another rectangle which is named “textPos”. This rectangle is part of the “gRowM” group and describes the attributes of the text to be rendered. The stroke colour describes the colour of the text to be rendered, the fill colour describes the background colour of the text, and its height determines which font size should be used.

Note that within the SVG file itself the relative position of the groups to each other has no effect on the software, only the relative position of the elements compared to the mask rectangle within a particular group.

The figure below shows how the SVG for a button might look in a SVG tool, such as Adobe Illustrator.

The figure below is an enlarged image showing how our software renders the above SVG button definition:

Each of our widgets use similar techniques to allow groups and masks to scale graphics to the appropriate size.

This simple mechanism using groups to provide scalable widget “skins” is used throughout the implementation. Some widgets require horizontal and vertical scalable elements in order to provide a flexible enough graphical appearance. In such cases 9 scalable elements are used. The menu widget is an extreme case, it has 9 groups for the body of the menu and 3 for the menu title.

As with widgets, each dialog that can be displayed has an associated SVG file. When a dialog is displayed the associated SVG file is rendered, providing the background graphics. The rendering process also identifies “named rectangles”  describing the position and attributes of each widget within the dialog. The figure below shows how an example SVG file might look for a “Channel List Dialog”.

When developing a dialog each rectangle that indicates widget position is given a name. The software developer uses these names in the C++ for the dialog to bind to the required widget at runtime.  You will see a rectangle named “dialogTitle” that represents the position and size of the dialog title. The stroke/fill is used by the widget to determine the colours to use for the text it represents, and the C++ itself defines the text to be displayed. Here the widget provides the internationalised text using the efficient mechanisms provided by the Cabot UI framework.

This method of dialog implementation couples the dialog SVG file to the C++ implementation, the C++ side relying on certain elements to be present in the SVG. Whilst this restricts the UI designer, it does ensure that the graphical treatment is complete, making verification by the customer easier. In addition, some DVB standards have requirements on the information displayed to the user which must be met in order to achieve certification. For example the UK D-Book ([6]), mandates that “now/next” information derived from DVB SI EIT tables must be presented.

The developer may still provide some functional flexibility to the designer by making the graphical elements optional. For example, in our DTR application the presence of a rectangle representing the video preview window within the SVG indicates to the software to display the video in a window rather than full screen behind the UI. In this case the video preview rectangle is described as an optional element.

The concept of optional elements can be used by the developer to provide other simple customisations to the designer.

These techniques provide a very simple method for both converting existing applications and developing new applications with SVG. To convert an existing application the developer simply has to replace the existing widgets and dialogs with their SVG equivalents, and provide simple SVG templates. Designers can then apply a graphical treatment to the SVG templates separately from the software development.

Of course just delivering the designer a set of SVG templates and a manual would not be a particularly interactive design experience. The good engineering practices followed in our SVG implementation make it easy to allow the discovery mechanism to use the local disk as the source for SVG and PNG files when they are rendered in Cabot’s Observatory product. This interactive experience gives the designer the ability to experiment with graphical techniques more freely, and visualise in detail the end product. Developing in Observatory allows the 256 colour palette restrictions to be lifted during development of a graphical treatment with a dynamically allocated colour palette. Designers can use PNG images more freely for pitching ideas that would be required to be converted to vectors in order to be viable on a target platform.

This implementation has given Cabot two new products for development of its applications, Designer Observatory and SVG Developer Observatory.

  • Designer Observatory – a standalone PC implementation of Cabot DVB software, along with a set of SVG templates used to render the application. Designers can use this implementation to develop new application treatments that can be directly used in finished products, or simply to mock up ideas to pitch for new work.

  • SVG Developer Observatory – aimed at the application developer, this PC based development suite contains pre-compiled Cabot Libraries, application source code, and SVG templates. Developers can use this to write new or extend existing applications and produce their own SVG templates for use with Designer Observatory.

Cabot engaged the design house Instrata ([7]) to produce three new graphical treatments for Cabot's existing DTR UI. In the early phases, before the Cabot SVG implementation was developed, Instrata pitched three graphical treatments using traditional techniques, delivering screenshot images. Once the three treatments were refined through discussion and re-work with the Cabot sales team, one treatment was chosen to be developed.

At this stage the Designer Observatory implementation was not complete and therefore not all the dialogs in the DTR application were converted to use SVG. However there was enough to begin work. Cabot had no direct experience of how much of a designer’s time and what level of support would be required. So for this phase of the work Instrata were engaged on a time and materials basis, with one Cabot engineer providing technical support on a part time basis. Documents were written describing both the widget set and the dialogs in the application to reduce the amount of support required.

In the space of two weeks elapsed time, during which new versions of Designer Observatory software were delivered to Instrata, the designer had completed 99% of the graphical treatment. Engineering support during this time was minimal, and mostly driven by the fact that Designer Observatory was still being developed as the designer completed the work.

The progress made by the designer was better than expected. During the process the ability for the designer to interactively “play” with the implementation meant that they relied less on the documentation and could get on with the work of producing the treatment. The designer could check the implementation for completeness whilst working, reducing the need for extra work after final delivery.

Engineers were able to integrate the SVG on the platform and investigate performance issues, updates from the designer were delivered every few days. The direct use of SVG on the platform enabled engineers to address performance issues by splitting the designer’s output into simpler shapes. This optimisation is achieved by putting less calculation load to the renderer. Using graphics tools it is possible to split designs into simpler shapes without changing the visual appearance of the graphical treatment. With the design produced by Instrata only two dialogs required such optimisation.

We have learnt from previous experience that rendering such a different graphical treatment for an existing Cabot application can consume three months’ worth of engineering effort. Using the new SVG method for producing graphical treatments for a DTR application requires just two to three weeks of designer’s effort and minimal engineering support, a dramatic saving in engineering effort and time to market. The design produced by Instrata in this initial implementation has since become the Cabot reference application.


Using SVG provides our customers with a number of unique competitive advantages:

  • Flexibility: A SVG based solution leverages powerful mature graphics tools far in advance of any toolkit or software it would be possible for Cabot to develop in required timescales.

  • Efficiency: SVG enables UIs to be easily created and modified without the constraints of traditional UI development which require engineering time and effort. In addition, greater re-use of graphical resources is encouraged through techniques offered by commercial graphics tools.

  • Quality: The perceived quality of the UI is greatly enhanced when graphical design experts are used. Cabot’s software is freed from the fixed styles offered by its UI framework.

  • Liberates existing applications: Robustly tested legacy applications can be deployed to different customers with radically different graphical treatments.

  • Cost effective: The benefits delivered by SVG enable manufacturers to reduce the development costs and engineering effort required to make differentiated UIs, leveraging often cheaper and more readily available design resource. No further software licensing costs are incurred when using Cabot’s SVG solution.

  • Increased speed to market: The features provided by SVG enable customised UIs to be built, simulated and tested in previously unachievable timescales. Graphical treatment of a UI that previously took several months to achieve can now be developed in weeks.

  • Hardware independence: The entire application can be developed within a PC environment before being moved to the target hardware. Observatory provides the opportunity for customers to visualise the interface in a real operating environment.

  • Complete UI reassurance: Observatory allows both the designer and customer to test a real application interactively, dramatically reducing the possibility of UI problems once the product has been deployed. This results in optimal consumer satisfaction and reduced support calls and product returns. Observatory implementations of applications can be used as a basis for a product specification.