About GraphApp

GraphApp is a C portability toolkit which allows programs to work on many operating systems and with many screen resolutions and depths. The aim is to be able to port C code from one platform to another, and for it to work 100% the same with no source code changes required.

How does it work?

GraphApp uses the underlying graphics system and operating system to create windows and draw to them. It attempts to provide a programming environment where all supported platforms have the same programming interface, so that an X-Windows program which only relies on GraphApp can be ported to Windows, and it will work without change.

This is source-code compatibility, not binary compatibility of the kind that Java attempts to support.

How does GraphApp differ from Java's AWT?

GraphApp is quite similar to Java's AWT graphics system, with a few important differences.

Firstly, GraphApp is designed to work with the C language, not Java, so it's not object-oriented. This is a major difference in style, but not really a difference in functionality.

GraphApp goes further than Java does in attempting to provide compatibility between different operating systems. GraphApp provides its own Unicode fonts and font rendering technique; it can guarantee that fonts and controls look and work the same on all platforms, down to the pixel level; it has a more interactive image loading method; internally it uses UTF-8 strings to hold Unicode characters, and as such does not suffer from a 65,536 character limit which some 16-bit Unicode implementations of Java and Python suffer from.

Why is GraphApp's font rendering better?

In Java, fonts are rendered using the underlying font system in the operating system. On a Windows machine, a Java program has access to Windows fonts. On a Linux machine, the same Java program has access to Linux fonts.

There are some problems with this approach to font rendering. If the underlying operating system does not have a Unicode font available, then no matter how internationalised the Java program is, it may not be able to render the appropriate international characters. For example, suppose a program needs to draw Greek letters to display a mathematical formula. If there is no Greek font on the operating system, the formula will not be drawn correctly. This is a major impediment to using Java Applets to create programs that work across the World Wide Web; there can never be a guarantee that something as simple as text will look the same on all browsers.

Additionally, even if international fonts exist on all platforms the Java program must run on, the fonts may all be produced by different vendors, and hence the displayed text will be of different sizes on each platform. Java implements abstractions called "geometry managers" to smooth over the differences present between font resolutions and vendors.

GraphApp has a different approach to portability. It supplies a few standard Unicode fonts with its distribution. The most important font is the GNU Unicode font, called Unifont. This implements some 35,000 characters from Unicode, and the list is growing. This is one of the most complete Unicode fonts available today, and it's free.

Because GraphApp uses its own font rendering technology, and supplies this font with all distributions, a GraphApp application can be assured that the correct font is available on the target platform.

Not only that, but the font is guaranteed to be the same at the pixel level on all platforms, so GraphApp programs can be tested on one platform, and known to look exactly the same on all platforms.

The portable Unicode fonts supplied with GraphApp are broken into separate files (called Subfonts) which allow efficient loading and caching. This is a better approach than some operating system font rendering engines, which were designed in a pre-Unicode era. Some of them load an entire font before allowing rendering, which, for a Unicode font, can be quite slow due the sheer size of Unicode. By contrast, Subfonts allow small pieces of a font to be loaded on demand.

GraphApp's font technology has a fall-back mechanism so that if a selected font does not contain a required character, then the system looks for that character in the default Unicode font instead. In effect, this means that new fonts can be created which just handle, say, English text, without having to handle all Chinese or Greek characters; not providing these characters is acceptable, since the system will just use the default glyphs for those characters. Hence, all of the Asian languages can be implemented once, in Unifont, and are thereafter present in all fonts.

This is an elegant solution to the font problem, and allows a programmer to be assured that the program will display text correctly wherever it is.

Do controls match the look and feel of the operating system?

GraphApp implements its own controls using basic drawing operations, and as such, the controls may look slightly different to the ones found in the operating system.

This is not a disadvantage, for the most part. And it has some advantages, because it allows a GraphApp program to do three things no operating-system-specific program can do:

1. A GraphApp program can guarantee that a button or text field can display Unicode text, correctly, the same way, on all platforms.
2. A GraphApp program can guarantee that a control looks the same on all platforms, down to the pixel level.
3. A GraphApp program can guarantee that a control behaves in exactly the same way on all platforms, hence reducing the need for different documentation for each platform, and reducing the amount of testing that must occur on each platform. This allows a programmer to write once, test once, run anywhere.