Graphic System Layer Project

The Graphic System Layer (GSL) project is an umbrella project to provide graphic output on different devices. Graphic output refers to a range of operations starting from simple line drawing to complex raster operations. Furthermore it contains a set of widgets and different APIs to make use of them. The most prominent examples for devices are of course computer displays and printer.

The Visual Class Library (VCL) is the most prominent module of the project. It contains implementations for fundamental concepts like windows, fonts, bitmaps, widgets (buttons, menus, ...) and so on. The infrastructure VCL provides is heavily used throughout all higher level infrastructure layer and the different OpenOffice.org application modules. VCL lets OpenOffice.org look and feel the way it does. VCL provides an external operating system independent API to higher level modules an internal API for implementing those in a system dependent manner. Current implementations provide support for Microsoft Windows and Unix/XWindow based systems. The latter is used for the Mac OS X port as well (A further project uses Java for implementation, however it's not hosted on OpenOffice.org). If you plan to port OpenOffice.org to a new platform then it's probably worth to have a look at VCL.

GSL and VCL are sometimes used as synonyms which is way too simple. GSL contains a lot more modules than just VCL, a complete list is given below.

Module	Function
Modules in the Graphic System Layer Project
`accessibility`	Accessibility tools bridges (e.g. java accessibility bridge)
awb	Accessibility workbench for checking accessibility bridges
awttools	Accessibility test programs
basebmp	Base classes for bitmap manipulation
canvas	Implementation of a new graphical output layer designed to replace vcl's OutputDevice
cppcanvas	C++ wrappers and helper classes for canvas
dtrans	System specific interchange (e.g. clipboard, drag and drop)
`forms`	Implementation of controls that can be used as forms in documents. Form controls are based on VCL.
fpicker	Support for system specific file dialogs and a generic fallback solution
`padmin`	Printer administration utility. Used on Unix platforms to configure printer queues and capabilities
`psprint`	Printer discovery and PostScript code generation. In conjunction with VCL it provides an application printing solution on Unix based systems. In the 3.2 codeline the psprint code has moved from its own modules into vcl to benefit from tighter integration.
`rsc`	Resource compiler. The basic layout of dialogs and the strings that are subject of translation/localization are stored in resource files. The resource compiler creates an efficient binary representation out of a human readable text format
shell	System integration: bindings to mailers and other external components
sysui	System desktop integration: mimetype and file type registration, quickstarter
`toolkit`	Toolkit provides a UNO API to VCL and UNO controls
`unocontrols`	A set of controls that do not directly rely on VCL. Currently implemented are a control for downloading files and an embeddable document preview.
`vcl`	Visual Class Library, implements graphic operations, window management and basic controls

What's going on for OpenOffice.org 3.2 ?

Printing recode

Currently on the Mac documents are first “printed” to a set of metafiles, then the actual Cocoa print job is started. This is necessary for two reasons: first for a print job you need to know the page range in advance (which the current vcl printer does not) and second individual pages are “pulled” from the print system in a random manner (e.g. the preview in the native print dialog prints a page to display it). The current mechanism works surprisingly well even for large documents but is naturally rather memory intensive.

So the plan is to move vcl's print model more in the direction of Cocoa's (that is to a model where the printer pulls pages instead of the application pushing all pages to the printer). Aside from the Mac specific advantage this gives us the opportunity for a better print dialog including a nice preview on all platforms. Also things like multipage printing can be done in an application independent manner this way.
Further Mac integration features

Netscape plugin support allows to embed e.g. shockwave/flash into our documents like on other platforms.
Improvements in OpenType font support

CFF based OpenType fonts should finally find better support (like rendering, printing and PDF export) in OpenOffice.org.
Performance

The overall performance of OpenOffice.org lets room for improvement. Currently there are no known big isolated issues that would result in huge performance gains, so we need to find lots of different small performance improvements. In the gsl area one example for these is the unification of different modules into one which will result in fewer libraries to load - noticeable especially on Windows where each library nowadays is subject to an antivirus scan.

What's going on for OpenOffice.org 3.1 ?

Printing recode (didn't make it into 3.1 due to time constraints)
StartCenter enhancements (didn't make it into 3.1, UX lost interest it seems)

The StartCenter in its current form will change its face and feature set; the UX team is currently thinking about its future directions. Actually this belongs to the framework project, but currently it looks like we will be helping them out.
Enhancements for RTL (Right To Left) languages

A lot of bug fixes and enhancements are on our list for arabic, hebrew and other RTL languages.
Further Mac integration features

While for 3.0 the main goal was bringing the Mac port up to the standards of the other platforms, we hope to strengthen it beyond this with further integration features. Support for the Apple Remote as well as Apple scripting is currently in development. Scripting support will start with simple things and over time make more features available through Apple script. Full scriptability is already possible through our existing scripting framework (most notably using BASIC) as well as through the UNO bridge to Java, Python and possible other languages.

What's going on for OpenOffice.org 3.0 ?

Mac/Aqua Port

The newly invigorated MacOSX (which is now a mainstream platform) porting effort involves a lot of work in gsl. Goal is to release a beta version along with the 3.0 beta on other mainstream platforms. Some issues involved in the port include:
- Porting vcl including native widget theming.
- Drag&Drop
- Support for Apple's font formats
- QuickTime support
- ...

What was going on for OpenOffice.org 2.x ?

Further PDF export enhancements

New features were added in 2.0.4: encrypted PDF and setting various user access permissions. Support for PDF/A-1a compliant output was added in 2.4.
Support for Unicode surrogates

OOo will be able to use Unicode characters outside the baseplane of 0x0000 to 0xffff if you have a font to render those characters.
Multiscreen support for presentation

First version available in 2.1.
Refactoring the toolkit for better use in UNO extensions

What was going on for OpenOffice.org 2.0 ?

System conforming look and feel

VCL provided a desktop and operating system independent look to OpenOffice.org 1.x. However most user preferred OpenOffice.org to look and behave according to their favorite desktop theme. In 2.0 VCL will pick up that theme, not by emulating it but simply by using the desktops very own methods to draw a control. Currently support for Windows XP and recent versions of Gnome as well as KDE with qt >= 3.2.2 is implemented.
Enhanced PDF support

OpenOffice.org 1.1 contained a basic PDF file export mainly preserving the visible content of a document. While this was already a big deal for most user, many provided feedback about being in need of more. In 2.0 more of the document content that can be matched to the PDF file format will be preserved. This is for example external and internal hyperlinks, table of contents, preview bitmaps for page preview, form controls, and much more.
Improvement of font discovery/matching

Not visible to the user, VCL does a huge job in finding fonts and making them available to the higher level applications. Over time the implementation had to take more and more feature. For 2.0 it needed some restructuring and maintenance to stay robust and performing.

What was going on for OpenOffice.org 1.x ?

All application windows based on system windows

The original implementation of OpenOffice.org used a single system window to implement all application windows. Whereas that provided fine grained control over the window behavior it was simply not possible to move a subwindow out of it's parents area. Good for developers, bad for users, however in the end the user won.
Asian language support

How to do proper support for Asian languages easily fills a book. However the main issues solved in VCL where proper keyboard input and extended text output features like vertical writing (from right to left)
Glyph fallback

The typical user does not really care about what characters can be represented by the glyphs from the current font he uses. To still allow him or her to see what's in the document, glyphs missing in the font are substituted if a richer font is found.
PDF file export

Creating PDF files with OpenOffice.org 1.0 was a bit tricky on Unix, and really, really tricky on Windows. OpenOffice.org 1.1 was the first version to contain the possibility to simply "Save as ..." pdf. Users loved it and asked for more.
Open source Unix printing system

It wasn't possible to open source the original StarOffice 5.x printing system because Sun didn't own it. Whereas Microsoft Windows already provides sufficient API to implement printing, on Unix there was nothing available at that time. In OpenOffice 1.0 psprint saw the light, an Asian language enable, PostScript based printing system.

Want more information ? Want to help ?

There is a simple way to find out more about GSL and it's role in OpenOffice.org. Just ask ! If you have questions then please post them in the dev@gsl mailing list. Please have a look here for contact information.

All trademarks found herein are property of their respective owners.

The Free and Open Productivity Suite