Java Doc for RenderingHints.java in  » 6.0-JDK-Core » AWT » java » awt » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Note that since these keys and values are hints, there is no requirement that a given implementation supports all possible choices indicated below or that it can respond to requests to modify its choice of algorithm. The values of the various hint keys may also interact such that while all variants of a given key are supported in one situation, the implementation may be more restricted when the values associated with other keys are modified. For example, some implementations may be able to provide several types of dithering when the antialiasing hint is turned off, but have little control over dithering when antialiasing is on. The full set of supported keys and hints may also vary by destination since runtimes may use different underlying modules to render to the screen, or to java.awt.image.BufferedImage objects, or while printing.

Implementations are free to ignore the hints completely, but should try to use an implementation algorithm that is as close as possible to the request. If an implementation supports a given algorithm when any value is used for an associated hint key, then minimally it must do so when the value for that key is the exact value that specifies the algorithm.

The keys used to control the hints are all special values that subclass the associated RenderingHints.Key class. Many common hints are expressed below as static constants in this class, but the list is not meant to be exhaustive. Other hints may be created by other packages by defining new objects which subclass the Key class and defining the associated values.

• Values should be a positive integer in the range 100 to 250.
• A lower value (eg 100) corresponds to higher contrast text when displaying dark text on a light background.
• A higher value (eg 200) corresponds to lower contrast text when displaying dark text on a light background.
• A typical useful value is in the narrow range 140-180.
• If no value is specified, a system or implementation default value will be applied.

TrueType fonts typically provide this information in the 'gasp' table. In the absence of this information, the behaviour for a particular font and size is determined by implementation defaults.

Note:A font designer will typically carefully hint a font for the most common user interface point sizes.

Notes:
An implementation when choosing whether to apply any of the LCD text hint values may take into account factors including requiring color depth of the destination to be at least 15 bits per pixel (ie 5 bits per color component), characteristics of a font such as whether embedded bitmaps may produce better results, or when displaying to a non-local networked display device enabling it only if suitable protocols are available, or ignoring the hint if performing very high resolution rendering or the target device is not appropriate: eg when printing.

These hints can equally be applied when rendering to software images, but these images may not then be suitable for general export, as the text will have been rendered appropriately for a specific subpixel organisation.

 (value==null ? v==null : value.equals(v))
 

This hint could control the choice of alpha blending calculations that sacrifice some precision to use fast lookup tables or lower precision SIMD instructions. This hint could also control whether or not the color and alpha values are converted into a linear color space during the calculations for a more linear visual effect at the expense of additional per-pixel calculations.

The allowable values for this hint are

• RenderingHints.VALUE_ALPHA_INTERPOLATION_SPEED
• RenderingHints.VALUE_ALPHA_INTERPOLATION_QUALITY
• RenderingHints.VALUE_ALPHA_INTERPOLATION_DEFAULT

A typical antialiasing algorithm works by blending the existing colors of the pixels along the boundary of a shape with the requested fill paint according to the estimated partial pixel coverage of the shape.

The allowable values for this hint are

• RenderingHints.VALUE_ANTIALIAS_ON
• RenderingHints.VALUE_ANTIALIAS_OFF
• RenderingHints.VALUE_ANTIALIAS_DEFAULT

When a rendering or image manipulation operation produces a color value that must be stored into a destination, it must first convert that color into a form suitable for storing into the destination image or surface. Minimally, the color components must be converted to bit representations and ordered in the correct order or an index into a color lookup table must be chosen before the data can be stored into the destination memory. Without this minimal conversion, the data in the destination would likely represent random, incorrect or possibly even unsupported values. Algorithms to quickly convert the results of rendering operations into the color format of most common destinations are well known and fairly optimal to execute.

Simply performing the most basic color format conversion to store colors into a destination can potentially ignore a difference in the calibration of the java.awt.color.ColorSpace of the source and destination or other factors such as the linearity of the gamma correction. Unless the source and destination ColorSpace are identical, to correctly perform a rendering operation with the most care taken for the accuracy of the colors being represented, the source colors should be converted to a device independent ColorSpace and the results then converted back to the destination ColorSpace . Furthermore, if calculations such as the blending of multiple source colors are to be performed during the rendering operation, greater visual clarity can be achieved if the intermediate device independent ColorSpace is chosen to have a linear relationship between the values being calculated and the perception of the human eye to the response curves of the output device.

The allowable values for this hint are

• RenderingHints.VALUE_COLOR_RENDER_SPEED
• RenderingHints.VALUE_COLOR_RENDER_QUALITY
• RenderingHints.VALUE_COLOR_RENDER_DEFAULT

Some rendering destinations may support a limited number of color choices which may not be able to accurately represent the full spectrum of colors that can result during rendering operations. For such a destination the DITHERING hint controls whether rendering is done with a flat solid fill of a single pixel value which is the closest supported color to what was requested, or whether shapes will be filled with a pattern of colors which combine to better approximate that color.

The allowable values for this hint are

• RenderingHints.VALUE_DITHER_DISABLE
• RenderingHints.VALUE_DITHER_ENABLE
• RenderingHints.VALUE_DITHER_DEFAULT

Rendering text to a low resolution device like a screen will necessarily involve a number of rounding operations as the high quality and very precise definition of the shape and metrics of the character glyphs must be matched to discrete device pixels. Ideally the positioning of glyphs during text layout would be calculated by scaling the design metrics in the font according to the point size, but then the scaled advance width will not necessarily be an integer number of pixels. If the glyphs are positioned with sub-pixel accuracy according to these scaled design metrics then the rasterization would ideally need to be adjusted for each possible sub-pixel origin.

Unfortunately, scaling each glyph customized to its exact subpixel origin during text layout would be prohibitively expensive so a simplified system based on integer device positions is typically used to lay out the text. The rasterization of the glyph and the scaled advance width are both adjusted together to yield text that looks good at device resolution and has consistent integer pixel distances between glyphs that help the glyphs look uniformly and consistently spaced and readable.

This process of rounding advance widths for rasterized glyphs to integer distances means that the character density and the overall length of a string of text will be different from the theoretical design measurements due to the accumulation of a series of small differences in the adjusted widths of each glyph. The specific differences will be different for each glyph, some being wider and some being narrower than their theoretical design measurements. Thus the overall difference in character density and length will vary by a number of factors including the font, the specific device resolution being targeted, and the glyphs chosen to represent the string being rendered. As a result, rendering the same string at multiple device resolutions can yield widely varying metrics for whole strings.

When FRACTIONALMETRICS are enabled, the true font design metrics are scaled by the point size and used for layout with sub-pixel accuracy. The average density of glyphs and total length of a long string of characters will therefore more closely match the theoretical design of the font, but readability may be affected since individual pairs of characters may not always appear to be consistent distances apart depending on how the sub-pixel accumulation of the glyph origins meshes with the device pixel grid. Enabling this hint may be desirable when text layout is being performed that must be consistent across a wide variety of output resolutions. Specifically, this hint may be desirable in situations where the layout of text is being previewed on a low resolution device like a screen for output that will eventually be rendered on a high resolution printer or typesetting device.

When disabled, the scaled design metrics are rounded or adjusted to integer distances for layout. The distances between any specific pair of glyphs will be more uniform on the device, but the density and total length of long strings may no longer match the theoretical intentions of the font designer. Disabling this hint will typically produce more readable results on low resolution devices like computer monitors.

The allowable values for this key are

• RenderingHints.VALUE_FRACTIONALMETRICS_OFF
• RenderingHints.VALUE_FRACTIONALMETRICS_ON
• RenderingHints.VALUE_FRACTIONALMETRICS_DEFAULT

Implicitly images are defined to provide color samples at integer coordinate locations. When images are rendered upright with no scaling onto a destination, the choice of which image pixels map to which device pixels is obvious and the samples at the integer coordinate locations in the image are transfered to the pixels at the corresponding integer locations on the device pixel grid one for one. When images are rendered in a scaled, rotated, or otherwise transformed coordinate system, then the mapping of device pixel coordinates back to the image can raise the question of what color sample to use for the continuous coordinates that lie between the integer locations of the provided image samples. Interpolation algorithms define functions which provide a color sample for any continuous coordinate in an image based on the color samples at the surrounding integer coordinates.

The allowable values for this hint are

• RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR
• RenderingHints.VALUE_INTERPOLATION_BILINEAR
• RenderingHints.VALUE_INTERPOLATION_BICUBIC

The allowable values for this hint are

• RenderingHints.VALUE_RENDER_SPEED
• RenderingHints.VALUE_RENDER_QUALITY
• RenderingHints.VALUE_RENDER_DEFAULT

Some implementations may be able to use an optimized platform rendering library which may be faster than traditional software rendering algorithms on a given platform, but which may also not support floating point coordinates. Some implementations may also have sophisticated algorithms which perturb the coordinates of a path so that wide lines appear more uniform in width and spacing.

If an implementation performs any type of modification or "normalization" of a path, it should never move the coordinates by more than half a pixel in any direction.

The allowable values for this hint are

• RenderingHints.VALUE_STROKE_NORMALIZE
• RenderingHints.VALUE_STROKE_PURE
• RenderingHints.VALUE_STROKE_DEFAULT

The allowable values for this hint are

• RenderingHints.VALUE_TEXT_ANTIALIAS_ON
• RenderingHints.VALUE_TEXT_ANTIALIAS_OFF
• RenderingHints.VALUE_TEXT_ANTIALIAS_DEFAULT
• RenderingHints.VALUE_TEXT_ANTIALIAS_GASP
• RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB
• RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR
• RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_VRGB
• RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_VBGR

• Values should be a positive integer in the range 100 to 250.
• A lower value (eg 100) corresponds to higher contrast text when displaying dark text on a light background.
• A higher value (eg 200) corresponds to lower contrast text when displaying dark text on a light background.
• A typical useful value is in the narrow range 140-180.
• If no value is specified, a system or implementation default value will be applied.

As the image is scaled up, there are no blocky edges and the interpolation should appear smoother and with better depictions of any edges in the original image than with BILINEAR . As the image is scaled down, even more of the original color samples from the original image will have their color information carried through and represented.
See Also:   RenderingHints.KEY_INTERPOLATION

As the image is scaled up, there are no blocky edges between the colors in the image as there are with RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR NEAREST_NEIGHBOR , but the blending may show some subtle discontinuities along the horizontal and vertical edges that line up with the samples caused by a sudden change in the slope of the interpolation from one side of a sample to the other. As the image is scaled down, more image pixels have their color samples represented in the resulting output since each output pixel recieves color information from up to 4 image pixels.
See Also:   RenderingHints.KEY_INTERPOLATION

As the image is scaled up, it will look correspondingly blocky. As the image is scaled down, the colors for source pixels will be either used unmodified, or skipped entirely in the output representation.
See Also:   RenderingHints.KEY_INTERPOLATION

TrueType fonts typically provide this information in the 'gasp' table. In the absence of this information, the behaviour for a particular font and size is determined by implementation defaults.

Note:A font designer will typically carefully hint a font for the most common user interface point sizes. Consequently the 'gasp' table will likely specify to use only hinting at those sizes and not "smoothing". So in many cases the resulting text display is equivalent to VALUE_TEXT_ANTIALIAS_OFF . This may be unexpected but is correct.

Logical fonts which are composed of multiple physical fonts will for consistency will use the setting most appropriate for the overall composite font.
See Also:   RenderingHints.KEY_TEXT_ANTIALIASING
since:
   1.6

Notes:
An implementation when choosing whether to apply any of the LCD text hint values may take into account factors including requiring color depth of the destination to be at least 15 bits per pixel (ie 5 bits per color component), characteristics of a font such as whether embedded bitmaps may produce better results, or when displaying to a non-local networked display device enabling it only if suitable protocols are available, or ignoring the hint if performing very high resolution rendering or the target device is not appropriate: eg when printing.

These hints can equally be applied when rendering to software images, but these images may not then be suitable for general export, as the text will have been rendered appropriately for a specific subpixel organisation. Also lossy images are not a good choice, nor image formats such as GIF which have limited colors. So unless the image is destined solely for rendering on a display device with the same configuration, some other text anti-aliasing hint such as RenderingHints.VALUE_TEXT_ANTIALIAS_ON may be a better choice.

Selecting a value which does not match the LCD display in use will likely lead to a degradation in text quality. On display devices (ie CRTs) which do not have the same characteristics as LCD displays, the overall effect may appear similar to standard text anti-aliasing, but the quality may be degraded by color distortion. Analog connected LCD displays may also show little advantage over standard text-antialiasing and be similar to CRTs.

In other words for the best results use an LCD display with a digital display connector and specify the appropriate sub-pixel configuration.
See Also:   RenderingHints.KEY_TEXT_ANTIALIASING
since:
   1.6

 (value==null ? v==null : value.equals(v))
 

The entrySet returned from a RenderingHints object is not modifiable. a Set view of the mappings contained in this RenderingHints.

 (t1.get(k)==null ? t2.get(k)==null : t1.get(k).equals(t2.get(k)))