Contents
Previous
Next
| UIX Developer's Guide |
Contents |
Previous |
Next |
This chapter describes the image generation features provided by UIX Dynamic Images, UIX's image generation framework. The chapter contains the following sections:
HTML content rendered by UIX Components and uiXML typically contains a number of images,
as specified via the HTML <img> element. Although the use of images
are very common, images are in no way required by UIX's core rendering
technologies. That is, particular UIX Components Renderer
implementations may choose to use images to improve the appearance of the
generated output, but are not required to do so. For example, UIX Components's
Browser Look And Feel Renderer implementations use images to
implement several user interface components, such as buttons and tab bars.
These same user interface components could be implemented by
another Renderer using simple text links instead of images,
without impacting client application code.
Although images are a widely used tool for presenting graphical information or improving the appearance of web pages, the use of images presents some problems which must be considered by the application developer. For example, images which include text (such the Browser Look And Feel implementation of the ButtonBean) are very difficult to translate. Such images can be a hindrance to the development of internationalized applications, as extra time and resources must be allocated for image translation. Images in general are also difficult to customize, as manually creating images with customized fonts, colors, or text can be a very slow process. Finally, images can be a barrier to personalization support, as the necessary images may not be available in the end user's preferred fonts and colors.
One solution to these image-related problems is simply to not use images.
UIX Components allows such a solution to be implemented simply by choosing to use
Renderer implementations which do not rely on images.
However, since most applications do take advantage of images, UIX provides
a solution for the localization, customization and personalization
problems faced by these applications. UIX's solution for these problems is
provided by the UIX Dynamic Images image generation framework.
UIX Dynamic Images provides the ability to generate images either statically,
prior to deployment, or dynamically, as the web application runs. UIX Dynamic Images's
ImageGenerator tool generates images, such as buttons and
tab bars, based on an XML description of the desired images and message
files containing translated text. Although static image generation is
an improvement over creating images manually, static image generation
can be a tedious solution, as all of the required images must be generated
before the application is deployed. To simplify the image generation
process, UIX Dynamic Images also provides support for dynamically generating via the
ImageProvider interface. Applications make requests to an
ImageProvider implementation at runtime, allowing the
ImageProvider to generate new images as necessary. UIX Components or
UIX-based applications can leverage UIX Dynamic Images's dynamic image generation without
writing any UIX Dynamic Images-specific code. For example, UIX Components's Browser Look And Feel
ButtonRenderer and TabBarRenderer classes
automatically make requests to a UIX Dynamic Images ImageProvider for
the necessary images. The fact that UIX Dynamic Images is used by certain UIX Components
Renderer implementations is completely transparent to the
application code.
Although UIX Dynamic Images solves the localization, customization and personalization problems presented by image use, the solution does impose a cost. UIX Dynamic Images require the graphical capabilities provided by Java's AWT graphics library. AWT, in turn, makes use of graphics support provided by the underlying platform. As such, UIX Dynamic Images can only successfully generate images in environments where graphical capabilities are available. For example, in Unix environments, an X server must be present to serve AWT's graphical needs. As this is a fairly new requirement for most middle tier environments, it is often necessary to perform system administration work to ensure that the runtime environment is correctly configured to meet the graphical requirements of AWT. As not all deployment environments are configured with graphical operations in mind, UIX Dynamic Images provide a number of options to alleviate this requirement, such as the UIX Dynamic Images servlet, which allows image generation work to be offloaded to a remote machine.
One of the fundamental tasks in translating a software application is localizing the application's user-presentable messages. To optimize this process, application developers place all translatable messages in message files, which are provided to the translation team for translation. This process breaks down when the application includes images which need to be translated. Image file formats, such as GIF, do not store text messages in an externalized, translatable format. To translate an image, the translator must use an image manipulation tool to view the image and discover the text to be translated. Once the text is translated, a new image containing the translated text must be created. Manually creating a translated image requires graphic design skills and can be a very time consuming activity. So, although translation teams may be capable of translating image files, the image translation process is an inefficient use of translation team resources.
One of the goals of UIX Dynamic Images is to simplify the
image translation process by automating the
most time consuming step in the translation process - the manual
creation of translated images.
The UIX Dynamic Images ImageGenerator tool generates
image-based user interface components, such as button and tab bar
images, based on a description of the desired images.
Images are described using an XML language defined by UIX Dynamic Images: the
ImageGenerator XML language.
The ImageGenerator XML document is provided to the ImageGenerator
tool as a command line argument. The ImageGenerator tool parses the
specified XML input file, determines the types and properties for each
entry in the document, and creates a GIF image file for each
requested image.
The following ImageGenerator XML sample document describes a single image:
<?xml version="1.0"?>
<ImageGenerator>
<button name="login">
<text>Login</text>
</button>
</ImageGenerator>
</pre>
The <button> element indicates that an image containing a
button should be generated.
The label for the button, "Login", is specified via the
<text> child element of the <button> element. The
button image can be generated with the following command line
(assuming the description has been stored in a file named "sample.xml"):
java oracle.cabo.image.tools.ImageGenerator sample.xmlAs a result, the following button, named "login.gif", is created.
Once an image is generated with the UIX Dynamic Images ImageGenerator tool, it can
be installed on a web server and accessed by the application via the
HTML <img> element.
In addition to buttons, UIX Dynamic Images contain built-in support for generating three other types of images: global buttons, colorized icons, and tab bars.
Global buttons are the circular iconic buttons, normally located at the top of web pages, which provide access to global application functionality. For example, global buttons are typically used to provide access to services such as the help system or login service. UIX Dynamic Images generate global buttons from a borderless, gray scale source icons. During image generation, the source icon is given a circular border and is colorized based on the disabled and selected state of the global button. The following ImageGenerator XML file describes has three entries for enabled, disabled and selected global buttons.
<?xml version="1.0"?>
<ImageGenerator>
<!-- An enabled help button -->
<globalButton name="help-enabled" source="help.gif"/>
<!-- A disabled help button -->
<globalButton name="help-disabled" source="help.gif" disabled="true"/>
<!-- A selected help button -->
<globalButton name="help-selected" source="help.gif" selected="true"/>
</ImageGenerator>The source icon, Help.gif, looks like this:
The following list shows the global buttons generated from the source icon:
Enabled button
Disabled button
Selected button
Colorized icon generation is similar to global button generation in that a simple transformation is applied to a source icon. In the colorized icon case, the transformation is trivial: the colors in the source icon are modified according to a "color scheme". The colorization is typically applied to images which are used to implement pieces of the application's user interface. For example, the Oracle Browser Look And Feel uses the following three images when rendering the UIX Components FooterBean:
Left footer icon
Middle footer icon
Right footer icon
In the default color scheme, page-level components such as the footer and global header are drawn with a blue background color. In order to change the color of these components, the images used to implement these components must be re-colorized. The following ImageGenerator XML document contains colorized icon entries for the three footer icons.
<?xml version="1.0"?>
<ImageGenerator>
<colorizedIcon name="footr" source="footr.gif"/>
<colorizedIcon name="footm" source="footm.gif"/>
<colorizedIcon name="footl" source="footl.gif"/>
</ImageGenerator>The ImageGenerator can be run with this document to produce new versions of these icons in which the colors have been adjusted for different color schemes. For example,
The tab bar is the primary navigation component, typically located at the top of the web page. The following image shows a tab bar with three tabs:
Tab bar images can be generated with the UIX Dynamic Images ImageGenerator by using
the<tabBar> ImageGenerator XML element. The following sample XML
code describes the tab bar shown above.
<?xml version="1.0"?>
<ImageGenerator>
<tabBar name="tabs" selectedIndex="1">
<tab>
<text>First Tab</text>
</tab>
<tab>
<text>Second Tab</text>
</tab>
<tab>
<text>Third Tab</text>
</tab>
</tabBar>
</ImageGenerator>
In addition to generating the tab bar image, the ImageGenerator also
generates an HTML image map for the tab bar. The image map is stored
in a ".map" file with the same name as the generated image. URLs for
each link in the tab bar are specified in the ImageGenerator XML
document via a "destination" attribute on each <tab> element.
Of the four predefined image types, only button and tab bar images are likely to be candidates for translation. Colorized icons are never translated. Although global button source icons may be customized for different locales, global buttons have no translatable text and are not included in the message translation process.
To generate
translated versions of button and tab bar images using the
UIX Dynamic Images ImageGenerator tool, an ImageGenerator XML document containing
entries for all buttons and tab bars must be created. Creating the
ImageGenerator XML document is typically the responsibility of the
application development team, not the translation team. Once the
ImageGenerator XML document has been created, it can be provided to
the translation team to be localized. The translation
team would then create new locale-specific translations of the
ImageGenerator XML document, in which each <text> element is
translated for the target locale. For example, the following shows
the original login button sample document after being (poorly) translated
to Japanese.
<?xml version="1.0"?>
<ImageGenerator>
<button name="login">
<text>争亊事</text>
</button>
</ImageGenerator>
The <text> been translated element has been translated from "Login" to a
Japanese string which is encoded as an escaped Unicode character
sequence. When the ImageGenerator is run on the translated document, the
following translated image is produced:
Although ImageGenerator XML documents are fairly easy to translate, ImageGenerator XML is not a standard message file format. As such, translation teams may be reluctant to support this new XML language. Ideally, the translation team should not need to be aware that translations are image-related. That is, from the translator's point of view, translating messages for images should be no different than translating messages for any other application content. Fortunately, UIX Dynamic Images allow such a solution to be implemented by taking advantage of the most commonly used Java message file format, the Java ResourceBundle.
Just as translatable messages are separated from application code to
ease translation, translatable messages can also be separated from
ImageGenerator XML documents. The <translatedText> element
is used in place of the <text> element to indicate that
the actual text string should be retrieved from a Java ResourceBundle.
The following sample shows a new version of the the login button
document which has been modified to use the <translatedText>
element.
<?xml version="1.0"?>
<ImageGenerator>
<defaults>
<!-- The ResourceBundle name -->
<bundle>SampleBundle</bundle>
<!-- The locales to generate: English, French and Japanese -->
<locale language="en"/>
<locale language="fr"/>
<locale language="ja"/>
</defaults>
<button name="login">
<translatedText key="LOGIN"/>
</button>
</ImageGenerator>
The document has been modified in three ways. First, the <text>
element has been replaced with a <translatedText> element, which
specifies the key to use when looking up the translated message in the
ResourceBundle. Next, a <bundle> element has been added in the
<defaults> section. This element specifies the fully qualified
Java class name of the ResourceBundle to use. Finally, a number of
<locale> elements have been added to the <defaults> section.
A separate set of images are generated for each <locale> element,
using the locale-specific ResourceBundle. Each set of generated images
is placed in a separate locale-specfic output directory.
Prior to running the ImageGenerator on the document, ResourceBundles for each locale must be created and compiled. The application development team is responsible for creating the ResourceBundle for the base locale (English). In this example, the ResourceBundle only requires a single message corresponding to the "LOGIN" key. This can be implemented as a standard Java ListResourceBundle:
import java.util.ListResourceBundle;
public class SampleBundle extends ListResourceBundle
{
public Object[][] getContents()
{
return contents;
}
static final Object[][] contents =
{
{"LOGIN", "Login"},
};
}The base ResourceBundle is provided to the translation team, which creates localized bundles for each locale. Once the bundles have been translated and compiled, translated versions of the images can be generated with the ImageGenerator.
Static image generation with the UIX Dynamic Images ImageGenerator simplifies the image translation process by removing the need to manually create translated images. However, there are a number of drawbacks to this new approach. For example:
To avoid these drawbacks, UIX Dynamic Images provide support for dynamic image generation. Dynamic image generation allows the application to make requests at runtime for the images it needs. If the necessary images are not already available, they can be generated by UIX Dynamic Images. This means that the set of images used by an application does not need to be defined ahead of time. No ImageGenerator XML document is required, as there is no single image generation step. Since images are created as needed, images can be dynamically generated with localized messages, or with customized or personalized colors and fonts.
Dynamic image generation requests are made to UIX Dynamic Images through the ImageProvider
API. The ImageProvider interface defines a single method:
getImage(). Applications pass information about the requested
images to the ImageProvider via the getImage() method. The ImageProvider
responds to the request by determining whether an image which meets the
desired requirements is available. If no such image exists, the
ImageProvider can create a new image which meets the
requirements. The ImageProvider then returns information about the
generated image, such as the location of the image for use in an URL.
The ImageProvider.getImage() method is defined as follows:
public ImageProviderResponse getImage(
ImageContext context,
ImageProviderRequest request
);
The ImageContext is analogous to the UIX Components
RenderingContext. The ImageProvider uses the
ImageContext to get information about the end user's environment, such as the end user's
locale. The ImageContext also provides access to global
context objects such as the ErrorLog and the
Configuration object. UIX Dynamic Images provide a single
ImageContext implementation: the ImageContextImpl.
Like UIX Components RenderingContext instances, UIX Dynamic Images
ImageContext instances encapsulate information about
a single HTTP request. Thus, UIX Dynamic Images clients can use a single
ImageContext instance for all calls to
getImage() while processing a single HTTP request. However,
ImageContext instances should not be reused across
multiple HTTP requests.
The ImageProviderRequest specifies both the type of image to generate
(button, tab bar, etc...), as well as the set of type-specific properties
which define the particular image that is needed. The type of image is
specified by both a namespace and a local name. Image types are partitioned
by namespace to allow clients to define custom image types without conflicting
with the predefined image type names. To request an image of one of the
predefined image types, the
UIX Dynamic Images namespace, defined by ImageConstants.TECATE_NAMESPACE,
is used. Name constants for the four built-in UIX Dynamic Images image types are
defined by the ImageConstants interface:
BUTTON_NAME, GLOBAL_BUTTON_NAME,
COLORIZED_ICON_NAME, and TAB_BAR_NAME.
The ImageProviderRequests provides information about the properties
of the requested image via the getRenderProperites()
method. This method returns a java.util.Dictionary object
containing the properties of the requested image.
the properties of the requested image. The keys for the requested
properties are defined by the ImageConstants interface.
The property values are type-specific. For example, the
ImageConstants.TEXT_KEY is used to specify the String
text label for button images. The ImageConstants.FOREGROUND_KEY
defines the java.awt.Color foreground color value to use when
rendering the button's text label. The
ImageProviderRequestImpl is a generic implementation
of ImageProviderRequest which wraps an arbitrary
Dictionary of image properties.
The following sample code shows how to request a "Login" button from an ImageProvider.
// Create the ImageContextImpl with the end user's locale, direction
// and the current ErrorLog.
ImageContextImpl context = new ImageContextImpl(localeContext,
agent,
colorScheme,
errorLog,
config);
// Create the dictionary of request properties. Since we only need
// a very small dictionary, we use oracle.bali.share.collection.ArrayMap
// instead of java.util.Hashtable.
ArrayMap properties = new ArrayMap(1);
properties.put(ImageConstants.TEXT_KEY, "Login");
// Create the ImageProviderRequest
ImageProviderRequest request = new ImageProviderRequestImpl(
ImageConstants.TECATE_NAMESPACE,
ImageConstants.BUTTON_NAME,
properties);
// Make the request to the ImageProvider
ImageProviderResponse response = imageProvider.getImage(context, request);
if (response != null)
{
// Render an img element using the location in the ImageProviderResponse
}
The ImageProviderResponse object returned from
ImageProvider.getImage() contains all of the information
needed by the application to generate an HTML <img> element for
the requested image. ImageProviderResponse.getImageURI()
returns the location of the image, which, after pre-pending a base URI,
can be used as the value of the <img> src attribute.
The width and height of the generated image is also reported via the
ImageProviderResponse. These values can be in turn be
specified as the width and height attributes
of the<img> element, which helps the browser to lay out pages more
efficiently. Finally, for composite components such as the tab bar,
the ImageProviderResponse can provide information about
the locations and sizes of the individual component regions. This
information can be used by the application to generate an HTML image map
for the image.
UIX Dynamic Images provides a single ImageProvider implementation: the
FileSystemImageCache. As the name implies, the
FileSystemImageCache uses the file system as the storage
mechanism for any images that it generates. The root directory of the
cache of images is specified when the FileSystemImageCache
instance is created. All images generated by the
FileSystemImageCache are stored under this directory.
In order to allow images to be accessed through an URL, the root directory
of the image cache must be in a location that is accessible via a web
server. For example, the image cache can be located somewhere under
the web server's document root, or under some other aliased directory that
the web server can access.
The URIs returned by the FileSystemImageCache are always
relative to the root directory of the cache. As such, it may be necessary
to pre-pend a base URI to the returned URI in order to generate a full
URL suitable for use as the source of an HTML <img> element.
For example, if the web server document root is located
at "D:\Apache\htdocs", and the root directory of the image cache is
"D:\Apache\htdocs\images\cache", the application would need to pre-pend the
base URI "/images/cache/" to any URIs returned from the
FileSystemImageCache.
Since image caches can use a significant amount of memory and disk
resources, FileSystemImageCache instances are shared
across all applications running in the same Java virtual machine.
A shared FileSystemImageCache instance can be obtained
via the FileSystemImageCache.getSharedCache() method,
which takes the root directory of the image cache as its only argument.
A single, shared instance of the FileSystemImageCache is
created for each unique root directory.
The following sample shows how to obtain a FileSystemImageCache:
FileSystemImageCache cache = FileSystemImageCache.getSharedCache(
"D:\Apache\htdocs\images\cache");
Note, however, that a real application would not use a hardcoded
root directory. The actual directory to use is entirely dependent on
the directory structure of the machine on which the application is
installed. For example, the directory corresponding to the URI
"/images/cache" could just as easily be
"/private/tomcat/webapps/root/images/cache" or some other directory.
Instead of using a
fixed value for the image cache root directory, the application should
allow the customer to specify this information at installation time, or
allow the value to be configured after the application is installed.
Alternatively, the directory can be derived dynamically using the
Servlet API. The ServletRequest.getRealPath() method
can be used to convert URLs to file system paths. So, the above example
would be better implemented as follows:
FileSystemImageCache cache = FileSystemImageCache.getSharedCache(
request.getRealPath("/images/cache"));
This use of getRealPath() causes the image cache to be created
in the web server directory corresponding to the "/images/cache" URL,
regardless of where that directory happens to be located on a particular
target machine.
When a FileSystemImageCache instance is first created,
the root cache directory is searched for existing images. The
FileSystemImageCache loads information about each image,
such as the image type, location and properties, into an in-memory cache. As
requests are made to the FileSystemImageCache for specific
images, the FileSystemImageCache first checks to see whether
information about the image is available in the in-memory cache. If
a match is found in the in-memory cache, an ImageProviderResponse
with the image information is returned.
If the
FileSystemImageCache can not find an image which satisfies
the request, a number of steps are performed. First, the requested image
is created in memory, using an instance of the ImageRenderer
interface. The ImageRenderer generates a
java.awt.Image instance based on the Dictionary
of requested properties specified by the ImageProviderRequest.
Once the AWT Image is created,
its data is retrieved and saved to an image file under the cache
directory. An entry is added to the in-memory cache, so that future
requests for the same image can be processed quickly. In addition to saving
the image data to the file system, a companion metadata file is created for
each image. The metadata file stores a complete description of the
corresponding image, including the type of image (for example, button,
tab bar, etc...) as well as all of the properties which define the
specific image instance (for example, the button's label, colors, fonts,
etc...).
The following example shows the contents of a metadata file corresponding to the "Login" button image.
<?xml version="1.0" encoding="UTF-8"?>
<ImageMetadata version="0.1">
<button width="59" height="26" direction="ltr" renderer="oracle.cabo.image.laf.browser.ButtonImageRenderer">
<foreground red="0" green="0" blue="0"/>
<background red="247" green="247" blue="231"/>
<font>
<name>dialog</name>
<size>12</size>
<style>plain</style>
</font>
<colorScheme namespace="http://www.example.org/myColorSchemeNS" name="default"/>
<text>Login</text>
</button>
</ImageMetadata>
The XML language used for image metadata is almost identical to the ImageGenerator XML language. Image metadata files share the same file name as the corresponding image. The extension ".imx" (short for ImageMetadata XML) is used for image metadata files.
Once images and their metadata have been created and cached, they remain
in the FileSystemImageCache forever. That is, once images
have been cached, they are persistent across servlet engine sessions.
Even after the servlet engine is stopped, all of the images and
corresponding metadata remain cached on the file system. When the
servlet engine is restarted, the FileSystemImageCache
reinitializes its in-memory cache based on the image files and
metadata files stored in the file system.
Image generation was original proposed to solve the problems
of image translation. Static image generation shifts the burden
from the translation team to the application development team, which
is required to maintain the ImageGenerator XML file and perform
generation and integration work. Dynamic image generation removes
these responsibilities from the application development team, at the cost
of coding against the UIX Dynamic Images ImageProvider API. As a
result, the image translation problem disappears!
When a UIX Dynamic Images-based application makes a request to an
ImageProvider for a button or tab bar image, the
application is responsible for passing the ImageProvider
any translated messages. For example, when requesting a button image,
the button's label is specified by the application using the
ImageConstants.TEXT_KEY. The translated version of the
image is automatically generated and cached, and the location of the
translated image is returned to the application. UIX Dynamic Images places no
restrictions on how the application obtains its translated messages.
No ImageGenerator XML document is necessary. Any message file format
or translation repository can be used. No post-translation generation or
integration work is required. As a result, the image translation process
become identical to, and hopefully integrated with, the translation process
for the rest of the application's content.
Image translation becomes a simple matter of passing the desired
locale-specific messages to the ImageProvider. In
much the same way, image customization and personalization can be
achieved simply by specifying customized or even personalized colors and
fonts when requesting an image. The UIX Dynamic Images ImageConstants
interface defines a number of properties which can be used to control the
appearance of the generated image, including the FONT_KEY,
BACKGROUND_KEY, and FOREGROUND_KEY. As was
the case with message translations, the ImageProvider places no
restriction on how fonts and colors are determined by the application.
The application is free to implement whatever customization and
personalization strategies it sees fit.
Dynamic image generation allows applications to incorporate localized, customized, and personalized images with very little effort. However, UIX provides an even easier solution. Instead of coding against the UIX Dynamic Images APIs, applications can leave image generation to UIX's HTML rendering technologies - UIX Components and uiXML.
The following bit of UIX code causes a button image to be generated and
rendered as an HTML <img> element:
<button xmlns="http://xmlns.oracle.com/uix/ui" text="Login"/>Similarly, clients that are coded directly against the UIX Components API can use the following code to render an image-based button.
ButtonBean button = new ButtonBean("Login");
button.render(renderingContext);
The ButtonBean's ButtonRenderer implementation
for the Browser Look And Feel makes use of dynamic image generation to
render the button. The ButtonRenderer performs the
following steps when called to render. First, the ImageProvider
is retrieved from the UIX Components RenderingContext. By
default, a FileSystemImageCache instance is used.
Applications can provide their own ImageProvider by
setting the ImageConstants.IMAGE_PROVIDER_PROPERTY on
the UIX Components RenderingContext. By default, the image cache is
created in the directory corresponding to the "/cabo/images/cache" URI.
The location of the image cache root directory is configurable via
the UIX Share Configuration API's
Configuration.IMAGES_CACHE_DIRECTORY property.
Next, the ButtonRenderer prepares the
ImageProviderRequest by building up a Dictionary
of requested image properties, based on the ButtonBean's
attribute values. Then, the image is requested from the
ImageProvider using an ImageContext retrieved
from the RenderingContext.getImageContext() method.
If the request to the ImageProvider is successful, the
ButtonRenderer proceeds to generate the appropriate HTML
for the button image, including rendering attributes such as the image
width, height and an alternate text. In the tab bar case, UIX Components also
renders the image map which is used to implement the tab bar links.
The ButtonRenderer also gracefully handles dynamic image
generation failures. In the event that the requested image
can not be generated, the ButtonRenderer generates
alternate, non-image content, such as a link, an <input> element,
or a <button> element.
The UIX Dynamic Images image generation framework provides a solution for the localization, customization and personalization problems associated with the use of images in web pages. UIX Dynamic Images eliminates the extra overhead involved in static image translation. Development costs are minimized through the use of higher level rendering technologies such as UIX Components or UIX, which hide the use of dynamic image generation from the application developer. However, these benefits come at the cost of some new requirements.
UIX Dynamic Images uses the Java 2D graphics API to render the contents of generated images. Java 2D provides advanced graphics features such as antialiasing of both graphics primitives and text. Java 2 also includes improved font handling support, which is critical for image generation in multilingual applications. Since the Java 2D API is part of the Java 2 platform, UIX Dynamic Images image generation does not work in JDK 1.1 environments. The Java 2 Runtime Environment is required.
AWT provides the low-level graphics capabilities required by UIX Dynamic Images for creating images. AWT has been part of the core Java platform since JDK 1.0. UIX Dynamic Images cannot run in runtime environments which do not support AWT.
Most Unix implementations of AWT use the X Window System to implement all graphical operations. As such, UIX Dynamic Images-based applications must have access to an X Window System server (an "X server"). Most Unix platforms ship with an X server as part of the standard operating system distribution. In order for dynamic image generation to succeed, an X server must be running, the application must be configured to connect the X server, and the X server security mechanisms must be configured to allow the application to access the X server. In the event that the necessary X server connection can not be established, an error message is logged to the servlet error log, and no new images are generated. UIX Components- and uiXML-based application will continue to function, with missing images replaced by alternate non-image content.
Some Unix environments may lack the basic hardware requirements, such as a frame buffer, needed to run an X server. These environments are typically referred to as "headless" environments. In the event that it is not possible to run an X server on a particular middle tier machine, a number of options are available to enable image generation. For example:
These solutions are described in more detail in X Server Configuration for Image Generation.
Generation of images which include text, such as buttons and tab bars, requires the use of fonts for text rasterization. Oracle provides a number of internationalized fonts with the Oracle9iAS product which can be used for multilingual image generation. For more information these fonts, see the Fonts section of the Installation chapter.
Finally, the FileSystemImageCache must have write-access to
some directory on the web server, in order to save any generated images
in a location which can be referenced via an URL. This directory must have
sufficient disk space to contain all of the images that can possibly be
generated by the application.