Back to résumé

Ghosted for ANT Ltd.  Published in Electronic Engineering Times.

ANT develops embedded communications software for the new wave of consumer electronics and Internet devices and has been developing browsers as well as e-mail clients for the UK and Europe since the early 90's.  Originally ANT targeted education markets, which typically have very small budgets, and so we had to learn to develop solutions that were cheap and that could be used in environments with extremely limited hardware resources - that is, slow processors and very little memory.

Many of the PC browsers are based on the original NCSA Mosaic code that the University of Illinois Urbana-Champaign created, which is simply too resource-costly for the market we were addressing at that time.  So to design efficiently for the education market we had to write our own code from the ground up.

ANT developed browsers for the original network computer, which was introduced in 1996. When Internet appliances came along not long after that, we recognized that our experience developing applications for resource-constrained environments uniquely qualified us to exploit this market, and to do it better than anyone else. For one thing, the new handheld devices and set-top boxes with Web access required an entirely new approach to browser design. It is not as simple as modifying a desktop browser for use in the new markets. Since we were not using any traditional browser code, we already had a head start.

Secondly, embedded applications are often limited to a 40-MHz processor and as little as 4 Mbytes of memory. Designing for this environment requires extremely tight and efficient code, of course, but we had a head start on this as well.

So we set out to adapt our Fresco browser for the embedded market, since Fresco's small, efficient code made it ideally suited for resource-constrained devices. In addition to the constraints mentioned above, we had to consider a number of challenges that OEMs face in staying competitive in today's market, and we knew we needed to offer a solution that would address as many of them as possible.

We faced a number of critical issues in adapting Fresco for the embedded market. Crucial among our objectives were enabling the fastest possible time-to-market, making the product portable across any CPU and OS, and providing maximum functionality within the constraints of devices with minimal system resources. 

Another major challenge was to make Web pages designed for desktop monitors viewable on the tiny screens of handheld devices as well as on the low resolution screens of televisions.  We also needed a way to allow an OEM to differentiate its product from those of its competitors and do it as fast as possible. Complicating the challenge was that we had to take into consideration that there are very few software engineers out there who know how to port browsers for the handheld and set-top box environments.

Another element was that traditionally, porting and customizing a browser takes many months. We knew that the key to developing a successful product was to drastically cut development time for the OEM, enabling them to integrate a browser into their product in a matter of weeks instead of months. And of course the more you shorten time to market the more you reduce costs. We also knew that a time-to-market bottleneck we had no control over was the OEM's lack of access to browser-writing expertise, so we decided to create a browser that required a minimum of coding at the OEM end.  Yet another design issue we faced was that Fresco had to allow for the fact that in devices that don't have hard disks, there can be no disk-based cache of fetched Web objects.  We also needed to provide a way for the OEM to design alternative user interfaces for specific applications as well as to create a distinctive identity for the OEM.

After considering all these factors, we began by structuring Fresco with three distinct layers: the portability layer, the application core containing the Fresco Web browser, and the GUI.

Portability is handled by the first layer, which contains the system-specific code.  The OEM modifies this component to port the browser environment to the product's hardware and OS. We designed this layer so that the fundamental code is all there; all the OEM has to do is adapt two or three thousand lines of code to address the differences from system to system, such as memory allocation, timers and non-volatile memory. Even then the customer doesn't have to create the code from scratch. We provide reference code that typically only needs to be adapted.

In this way we have drastically reduced the amount of expertise an OEM needs to create a browser. Tens of thousands lines of code, residing in the core layer, are already written for him. No expertise is needed other than an understanding of the OS and hardware. Not only does this address the problem of lack of expertise in creating browsers, it is a big factor in reducing time to
market. For example, if the OEM follows our recommendation to use Bitstream's TrueDoc for font rendering, then no font management code needs to be modified. 

We chose C rather than C++ or Java for our development language because virtually every CPU has a C compiler available. C doesn't tie us to a particular OS or CPU architecture, and the OEM developer can use the same body of code to build products based on any number of hardware platforms. Once you have implemented our portability environment on a particular CPU, OS and target platform, it is simply a matter of compiling the browser to use this platform. The developer might have three products, each requiring a different CPU or a different memory footprint, but the same body of code can be applied easily to all three.

Since Fresco is processor and operating-system independent, it can track changing CPU and OS decisions throughout the lifetime of a product range. When targeting a new platform, it is only the portability library, and not the application itself, that requires porting. Thus, a typical port requires the adaptation of less than 5,000 lines of simple glue code.

Separate APIs address the interfacing of independent TCP/IP stack, font manager, graphics library, memory management, timer/event support, and image libraries. This provides great flexibility to the system integrator when deciding which components are most appropriate to the application being designed.

The second layer contains the Fresco HTML 3.2 Web browser.  The OEM does not modify this layer because he does not need to.  The only layers the OEM needs to alter are the portability and GUI layers.    

In designing Fresco's core application we took a number of things into consideration. For example, even though detailed HTML specifications are easily available from W3C (the standards body responsible for defining HTML), and tools such as Weblint check HTML code for syntax and style, many Web page authors do not adhere to any HTML standard and perform virtually no checking of their HTML. Knowing this, we incorporated a sophisticated HTML parser that looks for non-conformities and variations and automatically corrects them before passing the markup through to the core engine.

Web browsers that display on non-computer screens such as televisions or PDAs often have less screen estate available to them than most authors cater to. This is most noticeable horizontally, where many pages are designed for a PC display with at least 640 pixels. To deal with this problem, we incorporated variable scaling of images and tables to strike a balance between readability and less-than-expected horizontal resolution.

To conserve system resources, we designed scalable algorithms that make the most efficient and economical use possible of memory and the CPU. A scalable algorithm is one where the amount of work to do increases linearly with the size of the data set being processed. A poorly scalable algorithm is one where the work increases disproportionately as the size of the data set to be processed increases.

Scalable algorithms are especially important in the implementation of HTML tables within Fresco. This means, for example, that as HTML pages become more complex over time, Fresco will retain its efficiency. For example, nesting of tables can result in N-squared, N-cubed, and even worse time and memory overheads in some other browsers. To assure that time and memory overheads are kept as near linear as possible in Fresco we developed a prioritized, constraints-solving algorithm that resolves conflicts between constraints with the least error.

Our choice of ANSI C as our programming language is another factor in efficient use of resources because native implementations require much less overhead in terms of the amount of code needed in a particular environment.

In embedded applications this can be extremely important. To use an
object-oriented language such as Java, you may need two or three times the memory footprint to hold both the code and the workspace.

The table below provides a code size breakdown within Fresco. No code compression is used to achieve these sizes. A further reduction in core size can be accomplished by removing specific HTML tag support. A customer might do this for specialized vertical markets, for example. The figures in the following list  come from an x86-targeted build.

Browser core, excluding the features below 330K

Portability code (platform specific) 100K

Resources (e.g. UI graphics) 110K

GIF 5K 

JPEG 62K

PNG 65K

XBM 2K

HTTP 15K

JavaScript / EcmaScript 160K

Fonts (Bitstream) 75K

SSL 432K 

The capability of the core is crucial, of course. But portability and customizability are also extremely important. Having a core that has all the functionality required but which takes six months to turn into a product isn't a solution at all, no matter how functional it is. Fast porting and fast customization are what the other two layers of Fresco are about.

The third layer in Fresco's architecture is the graphical user interface.  In this layer we provide another API and a graphics library that together allow the OEM to create his own distinctive user interface. A lot of products providing Web access such as set top boxes, PDAs and mobile phones are of a similar physical shape, color, and size, so the only thing that differentiates one product from another is what the user sees on screen and how the product behaves.

Time-to-market pressures make it essential that OEMs develop effective browsers as fast as possible, but the challenge of designing browsers for embedded systems requires new skills and new methodologies, and as stated earlier, we have found that most OEM software engineers have little or no experience to prepare them for meeting these stringent requirements. Worse, in some cases the relatively forgiving environments they are used to, with powerful processors and ample memory, have encouraged careless programming habits that are disastrous in resource-limited applications.

OEMs tell us they are having a hard time coming up with browsers that not only work well, but that make their devices distinctive and competitive. Our challenge was to make it easy for an OEM to create the graphic interface that best reflects the  individual brand identity. ANT's name does not appear on the browser, only the OEM's name or brand.

Building the GUI is completely decoupled from the porting process so that the custom interface can be developed prior to the availability of a working hardware platform. The OEM doesn't even have to know yet which CPU and OS he is going to use, but once those decisions are made the GUI can be recompiled immediately to the target hardware. In addition, once the browser is customized it is easy to adapt for any changes in the hardware, and to migrate it to a different platform altogether. This is one of the primary strategies we used to reduce time-to-market.

The API layers in Fresco allow customization to be carried out without affecting the basic browser core. This structuring enables Fresco to be quickly and effectively incorporated into a wide variety of application environments ranging from highly embedded applications, requiring no user front end, to a fully loaded, browser-based system operating as a user
environment from which other applications may be launched.

Small screens

Small screens deserve special comment. Not only must a browser be able to display Web content on screens much smaller than those available on desktops and laptops, Web pages at the server end are often designed to be read on desktop/laptop screens; they do not scale easily to a screen the size of a PDA. Tables are especially daunting to get to run correctly.

To make Web pages viewable on a tiny screen, tables, images, and fonts have to be scaled. But if you scale an image down to fit the width of the screen, it might be so small you can't see what it is. In the case of a picture, this might be merely irritating, but if you shrink a graphic with text too far you can't read the text and this is unacceptable. You might also break the linkage on the site because the user can't see where the links are.

There's a precarious balance to be struck between making components of the page fit within the screen, but not so far that the images are unreadable and therefore useless.

In the case of set-top boxes, browsers must compensate for the relatively low resolution of a TV screen compared to that of a computer monitor.  They must also address issues related to TV interlacing to ensure that the quality of print and photos is retained.

The issue of small screens and low resolution on TV screens can be addressed at the server end as well as at the client end. Server software can detect what browser is being used to access the site, and we are beginning to see servers that provide variants of their pages customized for particular browsers. Motivated by the need to accommodate as many visitors as possible to keep market share, some Web sites have as many as twenty different versions of their pages. As this trend grows, it will go a long way toward simplifying the display of Web pages on small-screen devices.

In the future we expect to see OEMs trying to find ways to enable voice activation or plug-ins like Macromedia Shockwave on handheld devices and set-top boxes. The challenge will continue to be how to take richer and richer formats for information and reproduce them in resource-constrained environments.

Back to top           Back to résumé

Back to Word Sculptors main page