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.

Modules
in the Graphic System Layer Project

Module

Function

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

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

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.

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 psprintsaw
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
herefor contact information.

Apache and the Apache feather logo are trademarks of The Apache Software Foundation.
OpenOffice, OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation.
Other names appearing on the site may be trademarks of their respective owners.