How does it work?
This is source-code compatibility, not binary compatibility of the kind that Java attempts to support.
How does GraphApp differ from Java's AWT?
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?
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?
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: