14 Features

<?xml version="1.0" encoding="utf-8"?
>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang=
"en-US">
<head>
<title>Java 2D Features in Java SE 1.4</title>
<link rel="stylesheet" type="text/css"
href="../../../technotes/css/guide.css" />
</head>
<body>


<div id="javaseheader">
<div id="javaseheaderlogo">
<img src="../../../images/javalogo.gif"
alt="Java logo" />
</div>
<div id="javaseheaderindex">
<a href=
"../../../index.html">Documentation Contents</a>
</div>
<div class="clear"></div>
</div>

<h1>Java 2D Features in Java SE 1.4</h1>
<ul>
<li><a href="#PA">New Pipeline Architecture</a></li>
<li><a href="#VI">Hardware Acceleration for OffscreenImages</a></li>
<li><a href="#IO">Pluggable Image I/OFramework</a></li>
<li><a href="#UP">New Java Print Service API</a></li>
<li><a href="#IT">Support for additional ImageTypes</a></li>
<li><a href="#BA">Public Bidi Algorithm</a></li>
<li><a href="#FH">Font Rasterizer support for TrueType Hinting</a></li>
<li><a href="#LF">Hinted Lucida Fonts</a></li>
<li><a href="#OT">OpenType Font Table Support</a></li>
<li><a href="#AN">Support for Numeric Shaping</a></li>
<li><a href="#CL">Improved Complex Text Layout Support</a></li>
<li><a href="#PD">Complete Porter-Duff Support</a></li>
<li><a href="#TA">Support for Checking if Font has a Transform</a></li>
<li><a href="#FE">New Equality Methods for FontRenderContext</a></li>
</ul>
<hr size="3" noshade="noshade" />
<a name="PA" id="PA">New Pipeline Architecture</a>
The bugtraq reports that correspond to this change are: <a href=
"http://bugs.java.com/view_bug.do?bug_id=4228939">4228939</a> and
<a href=
"http://bugs.java.com/view_bug.do?bug_id=4268962">4268962</a>
In the JDK 1.2 and 1.3 common operations on a
<tt>Graphics</tt> object often invalidated the rendering data
cached for this <tt>Graphics</tt> object. This invalidation
interrupted the rendering process by causing continuous re-creation
of rendering information for the <tt>Graphics</tt> object, even for
such simple and benign operations as <tt>create()</tt>,
<tt>setColor()</tt>, and <tt>translate()</tt>. Because the
rendering of Swing hierarchies relies heavily on these common
operations, the invalidation and re-creation of rendering data
caused poor repaint performance for many Swing applications.
The new pipeline architecture reduces this performance overhead
with several implementation changes that:

<ul>
<li>Improve the way that data is shared by the various rendering
pipelines.</li>
<li>Reduce the amount of code executed and garbage created when
responding to changes in the rendering attributes.</li>
<li>Improve the way that various graphics routines are chosen such
as the routines that copy pixels from one format and location to
another.</li>
</ul>
These changes are especially noticeable when the following calls
are used frequently, as they are in Swing applications:
<ul>
<li><tt>getGraphics</tt>, <tt>Graphics.create()</tt> and
<tt>Graphics.dispose()</tt></li>
<li><tt>Graphics.setColor()</tt>, <tt>Graphics.translate</tt></li>
<li><tt>Graphics.copyArea</tt>, especially when the source and
destination regions overlap.</li>
</ul>
The runtime footprint should also be improved through better code
sharing.
Other changes in the pipeline architecture have greatly improved
the performance of:
<ul>
<li><tt>draw(Shape)</tt> and <tt>fill(Shape)</tt>, especially when
the <tt>Shape</tt> is a <tt>GeneralPath</tt></li>
<li>scaled <tt>drawImage</tt>.</li>
<li>Blitting from an offscreen image created with
<tt>createImage()</tt> multiple times without any intervening
rendering or modifications to that image</li>
<li>Remote X11 display over the network of applications that use
<tt>createImage()</tt> to create an image buffer for double
buffering.</li>
<li>Rendering non-opaque text.</li>
<li>Systems, such as the SGI Visual 320 workstation, which have
display cards that use an RGBx format for pixel storage.</li>
<li>Rendering coordinates outside of the range -32768 to 32767 with
antialiasing turned off.</li>
</ul>
For more information on this feature, see the whitepaper, <a
href="http://www.oracle.com/technetwork/java/perf-graphics-135933.html">High
Performance Graphics</a>.
<a name="VI" id="VI">Hardware Acceleration for Offscreen
Images</a>
The bugtraq report that corresponds to this change is: <a href=
The JDK 1.4 provides access to hardware acceleration for
offscreen images, resulting in better performance of rendering to
and copying from these images. One problem with
hardware-accelerated images is that, on some platforms such as
Microsoft Windows, their contents can be lost at any time due to
circumstances beyond the application's control. The new
<tt><a
href="../../../api/java/awt/image/VolatileImage.html">VolatileImage</a></tt>
class allows you to create a hardware-accelerated offscreen image
and manage the contents of that image.
This new API includes:
<ul>
<li><tt>java.awt.image.VolatileImage</tt>: 
This class represents an image whose content can be lost at any
time, but provides performance benefits. For example, on Microsoft
Windows this image can be stored in VRAM and can benefit from
hardware acceleration. The class includes methods that you can call
to find out if the contents of the image need to be restored.</li>
<li><tt><a href=
"../../../api/java/awt/Component.html#createVolatileImage-int-int-">
createVolatileImage(w,h)</a></tt> in Component. 
This method creates a <tt>VolatileImage</tt> that is compatible
with the <tt>Component</tt>.</li>
<li><tt><a href=
"../../../api/java/awt/GraphicsConfiguration.html#createCompatibleVolatileImageint-int-">
createCompatibleVolatileImage(int width, int height)</a></tt> 
This method creates a <tt>VolatileImage</tt> that is compatible
with the <tt>GraphicsConfiguration</tt>.</li>
<li><tt><a href=
"../../../api/java/awt/GraphicsDevice.html#getAvailableAcceleratedMemory--">
GraphicsDevice.getAvailableAcceleratedMemory</a></tt> 
This method returns the number of bytes of available accelerated
memory.</li>
</ul>
<a name="IO" id="IO"></a>Pluggable Image I/O
Framework
The Java Image I/O API is an
pluggable, extensible framework that supports reading and writing
images of various formats and protocols. The API provides this
support through plug-ins, most of which will be written by third
parties. A conforming implementation will only be required to
provide a minimal set of plug-ins, principally for compatibility
with previous versions of the Java SDK. An application using this
API should be able to read and write images without knowing the
image's storage format or the plug-in used to support the
format.
Fundamentally, all image I/O operations consist of reading or
writing streams that contain one or more images, one or more
preview (thumbnail) images associated with each image, and
metadata, which is everything other than pixel data.
The Java Image I/O API allows applications to:
<ul>
<li>Auto-detect installed plug-ins</li>
<li>Choose plug-ins based on format name, file suffix, file
contents, or MIME type</li>
<li>Access individual images in multi-image files</li>
<li>Monitor reading and writing progress</li>
<li>Provide progressive updates of images being loaded</li>
<li>Read or write only a region of interest of an image</li>
<li>Read only selected bands of an image</li>
<li>Choose the output size of resolution-independent imagery</li>
<li>Retrieve detailed image and stream metadata</li>
<li>Work with unknown formats using generic interfaces</li>
<li>Work efficiently with both random-access and streaming data
sources</li>
<li>Transcode between different formats</li>
</ul>
See <a href="../imageio/index.html">Java Image I/O</a> for more
information on the Java Image I/O API.
<a name="UP" id="UP">New Java Print Service</a>
The bugtraq reports that corresponds to this change are: 
<a href=
"http://bugs.java.com/view_bug.do?bug_id=4285177">4285177</a> and
<a href=
This API is the product of JSR006, Unified Printing API, and
will allow client applications to provide rich access to the
capablities of print services available including:
<ul>
<li>Printer browsing and selection</li>
<li>Discovery of the capablities of printers</li>
<li>Selection of printers for a printer job</li>
<li>Specification of a printer job.</li>
</ul>
Since all capabilities will be exposed through the API, server
applications become first class citizens of this API.
Server applications can be beneficiaries of the capabilities for
spooling documents to print services, whereas previously only
graphics calls could be used to generate printer jobs from Java
applications.
See <a href="../jps/index.html">Java Print Service</a> for more
information.
<a name="IT" id="IT">Support for float and double Image
Types</a>
Prior to the SDK 1.4, the Java 2D API did not have
<tt>DataBuffer</tt> subclasses for float or double sample types.
The Java Image I/O API needs these classes to read and write float
and double image types.
The SDK 1.4 contains two new classes to provide float and double
image type support: <tt><a href=
"../../../api/java/awt/image/DataBufferFloat.html">DataBufferFloat</a></tt>
and <tt><a href=
"../../../api/java/awt/image/DataBufferDouble.html">DataBufferDouble</a></tt>.
The <tt>DataBufferFloat</tt> class wraps float arrays of pixels.
The <tt>DataBufferDouble</tt> class wraps double arrays of
pixels.
The existing <tt><a href=
"../../../api/java/awt/image/ComponentColorModel.html">ComponentColorModel</a></
tt>
and <tt><a href=
"../../../api/java/awt/image/ComponentSampleModel.html">ComponentSampleModel</a>
</tt>
class implementations have also been updated to support signed
short,float, and double data. These classes include definitions of
the normalized ranges of component values for the newly-supported
data types:
<ul>
<li>For the existing data types, the range remains 0.0 to 1.0.</li>
<li>For short data, the values are scaled to between -1.0 and
1.0.</li>
<li>For float data, the range is the full range of the float
primitive type.</li>
<li>For double data, the range is also the range of the float
primitive type, since values must be cast to float to interact with
the ColorSpace class.</li>
</ul>
The <tt>ComponentColorModel</tt> class will not clamp the pixel
data. Applications are expected to scale to the appropriate range.
Methods are added to the <tt><a href=
"../../../api/java/awt/color/ColorSpace.html">ColorSpace</a></tt>
class to determine per component minimum and maximum normalized
values. Alpha component values must still range from 0.0 to 1.0
normalized.
The complete additional API is listed below.
<tt><a href=
"../../../api/java/awt/image/ColorModel.html">java.awt.image.ColorModel</a></tt>
includes three new methods to parallel existing methods:
<ul>
<li><tt>getDataElement(float[] normComponents, int
normOffset)</tt></li>
<li><tt>getDataElements(float[] normComponents, int normOffset,

Object obj)</tt></li>
<li><tt>getNormalizedComponents(Object pixel, float[]
normComponents, int normOffset)</tt></li>
</ul>
<tt><a href=
"../../../api/java/awt/image/ComponentColorModel.html">java.awt.image.ComponentC
olorModel</a></tt>
includes a new constructor based on the new datatypes and new
methods to override the existing <tt>ColorModel</tt> methods:
<ul>
<li><tt>ComponentColorModel(ColorSpace colorSpace, boolean
hasAlpha, boolean isAlphaPremultiplied, int transparency, int
transferType)</tt></li>
<li><tt>getRed(Object inData)</tt></li>
<li><tt>getGreen(Object inData)</tt></li>
<li><tt>getBlue(Object inData)</tt></li>
<li><tt>getAlpha(Object inData)</tt></li>
<li><tt>getDataElements(int rgb, Object pixel)</tt></li>
<li><tt>coerceData(WritableRaster raster, boolean
isAlphaPremultiplied)</tt></li>
<li><tt>createCompatibleWritableRaster(int w, int h)</tt></li>
<li><tt>createCompatibleSampleModel(int w, int h)</tt></li>
</ul>
<tt><a href=
"../../../api/java/awt/image/SampleModel.html">java.awt.image.SampleModel</a></t
t>
includes two new methods to accept the new datatypes:
<ul>
<li><tt>getDataElements(int x, int y, int w, int h, Object obj,
DataBuffer data)</tt></li>
<li><tt>setDataElements(int x, int y, int w, int h, Object obj,
DataBuffer data)</tt></li>
</ul>
<tt><a href=
"../../../api/java/awt/image/ComponentSampleModel.html">java.awt.image.Component
SampleModel</a></tt>
includes two methods to accept the new datatypes:
<ul>
<li><tt>createDataBuffer()</tt></li>
<li><tt>getDataElements(int x, int y, Object obj, DataBuffer
data)</tt></li>
</ul>
<tt><a href=
"../../../api/java/awt/image/BandedSampleModel.html">java.awt.image.BandedSample
Model</a></tt>
has three methods that were edited to accept the new datatypes:
<ul>
<li><tt>createDataBuffer()</tt></li>
<li><tt>getDataElements(int x, int y, Object obj, DataBuffer
data)</tt></li>
<li><tt>setDataElements(int x, int y, Object obj, DataBuffer
data)</tt></li>
</ul>
<tt><a href=
"../../../api/java/awt/color/ColorSpace.html">java.awt.color.ColorSpace</a></tt>
includes two new methods determine per component minimum and
maximum normalized values:
<ul>
<li><tt>getMinValue(int component)</tt></li>
<li><tt>getMaxValue(int component)</tt></li>
</ul>
<tt><a href=
"../../../api/java/awt/color/ColorSpace.html">java.awt.color.ICC_ColorSpace</a><
/tt>
includes new methods override the two new <tt>ColorSpace</tt>
methods.
<a name="BA" id="BA">Public Bidi Algorithm</a>
The Unicode Bidirectional Algorithm analyzes text using the
Unicode character properties and determines the direction of runs
of the text. The algorithm is necessary to properly display
bidirectional text, such as Hebrew and Arabic text, in the correct
order.
The current implementation is all written in the Java
programming language, but the SDK 1.4 will include efficient access
from native font code so that Hebrew and Arabic text can be more
efficiently rendered. The SDK 1.4 will provide access to the native
code through the Java Native Interface.
The new public <tt><a href=
"../../../api/java/text/Bidi.html">Bidi</a></tt> class implements
the Unicode 3.0 Bidi Algorithm and allows access to information on
the bidirectional reordering of text so that the mixed,
bidirectional text is properly displayed.
The example <a href="samples/BidiSample.java">BidiSample</a>
demonstrates some of the <tt>Bidi</tt> routines.
<a name="FH" id="FH">Font Rasterizer support for TrueType
hinting</a>
Before this release, the T2K font rasterizer used by Java 2D did
not support font-hinting for TrueType fonts. As a result, when
TrueType fonts did not always display with a consistent, attractive
appearance. For this release, the T2K rasterizer has been modified
to use the hints stored in the TrueType fonts.
By adding this functionality to the T2K rasterizer, dependency
on native rasterizers has been greatly reduced. Reducing this
dependency results in:
<ul>
<li>Greater portability because hinting of TrueType fonts is
performed by the cross-platform T2K rasterizer, not the native
rasterizer.</li>
<li>More consistent metrics display of TrueType fonts because the
same rasterizer is being used for on-screen and off-screen
drawing.</li>
</ul>
<a name="LF" id="LF">Hinted Lucida Fonts</a>
For the SDK 1.4, the Lucida fonts that are in the Java SE
will be upgraded to contain hints. This will give the Java SE
higher quality fonts that could be used in place of existing fonts
or if no other fonts are available. Adding hints to the Lucida
fonts also allows the new cross-platform rasterizer to hint the
Lucida fonts contained in the SDK, which causes the Lucida fonts to
be displayed in a more consistent and attractive manner.
<a name="OT" id="OT">OpenType Font Table Support</a>
The SDK 1.4 includes a new architecture for providing general
OpenType font support. This new architecture provides international
character support for contextual scripts like Thai, Indic, Arabic,
and Hebrew. It also provides enhanced typographical support for
Roman languages.
<a name="AN" id="AN">Support for Numeric Shaping</a>
Currently, when Java 2D renders numerals surrounded by Arabic
text, the numerals have Arabic (roman) shapes, which are the
commonly expected numeral shapes in most western countries.

However, people in a Hindi locale expect to see Hindi shapes.
A new attribute, <tt><a href=
"../../../api/java/awt/font/TextAttribute.html#NUMERIC_SHAPING">TextAttribute.NU
MERIC_SHAPING</a></tt>,
and a new class, <tt><a href=
"../../../api/java/awt/font/NumericShaper.html">NumericShaper</a></tt>,
enable you to shape ASCII digits to other Unicode decimal
ranges.
For example, to cause a <tt>TextLayout</tt> instance to convert
digits from European to Arabic:
<ol>
<li>Create a <tt>NumericShaper</tt> that shapes ARABIC digits:
<pre>
Numeric Shaper nS
= NumericShaper.getContextualShaper(NumericShaper.ARABIC)
</pre></li>
<li>Add the <tt>NumericShaper</tt> to an attribute <tt>Map</tt>
along with the key value of <tt>TextAttribute.NUMERIC_SHAPING</tt>:
<pre>
Map map = new HashMap();
map.put(TextAttribute.NUMERIC_SHAPING, nS);
</pre></li>
<li>Create a <tt>TextLayout</tt> with the attribute <tt>Map</tt>:
<pre>
FontRenderContext frc = ...;
TextLayout layout = new TextLayout(text, map, frc);
</pre></li>
<li>Render the text:
<pre>
layout.draw(g2d, x, y);
</pre></li>
</ol>
The <tt>NumericShaper</tt> class includes 19 constants
representing different Unicode decimal ranges, allowing you to
convert to 19 different digit shapes, including Devanagari and
Thai.
<a name="CL" id="CL">Improved Complex-Layout Support in
GlyphVector</a>
Prior to this release, clients could not access
glyph-to-character mapping information from <tt><a href=
"../../../api/java/awt/font/GlyphVector.html">GlyphVector</a></tt>.
Clients can use this information to find out which glyphs in the
<tt>GlyphVector</tt> correspond to which characters. This release
also defines new methods to get the precise bounds of the
<tt>GlyphVector</tt> and of individual glyphs within a
<tt>GlyphVector</tt>.
Note: Although clients can use <tt>GlyphVector</tt> and the
glyph-to-character mapping information to implement selection and
hit testing, most clients will find TextLayout and the Swing
JTextArea and JTextField classes to be more useful and
convenient.
These <tt>GlyphVector</tt> methods are new in the SDK 1.4:
<ul>
<li><tt><a href=
"../../../api/java/awt/font/GlyphVector.html#getGlyphCharIndex-int-">
getGlyphCharIndex(int glyphIndex)</a></tt> 
Returns the character index of the specified glyph. The character
index is the index of the first logical character represented by
the glyph.</li>
<li><tt><a href=
"../../../api/java/awt/font/GlyphVector.html#getGlyphCharIndices-int-intint:A-">
getGlyphCharIndices(int beginGlyphIndex, int numEntries, int[]
codeReturn)</a></tt> 
Returns the character indices of the specified glyphs.</li>
<li><tt><a href=
"../../../api/java/awt/font/GlyphVector.html#getGlyphOutline-int-float-float-">
getGlyphOutline(int glyphIndex, float x, float y)</a></tt> 
Returns a <code>Shape</code> whose interior corresponds to the
visual representation of the specified glyph within this
<code>GlyphVector</code>, offset to x, y.</li>
<li><tt><a href=
"../../../api/java/awt/font/GlyphVector.html#getPixelBoundsjava.awt.font.FontRenderContext-float-float-">
getPixelBounds(FontRenderContext renderFRC, float x, float
y)</a></tt> 
Returns the pixel bounds of this <code>GlyphVector</code> when
rendered in a graphics with the given
<code>FontRenderContext</code> at the given location.</li>
<li><tt><a href=
"../../../api/java/awt/font/GlyphVector.html#getGlyphPixelBounds-intjava.awt.font.FontRenderContext-float-float-">
getGlyphPixelBounds(int index, FontRenderContext renderFRC, float
x, float y)</a></tt> 
Returns the pixel bounds of the glyph at index when this
<code>GlyphVector</code> is rendered in a <code>Graphics</code>
with the given <code>FontRenderContext</code> at the given
location.</li>
</ul>
These new <tt><a href=
"../../../api/java/awt/font/GlyphMetrics.html">GlyphMetrics</a></tt>
methods deal with transformed fonts:
<ul>
<li><tt><a href=
"../../../api/java/awt/font/GlyphMetrics.html#getAdvanceX--">getAdvanceX()</a></
tt> 
Returns the x-component of the advance of the glyph.</li>
<li><tt><a href=
"../../../api/java/awt/font/GlyphMetrics.html#getAdvanceX--">getAdvanceY</a></tt
> 
Returns the y-component of the advance of the glyph.</li>
</ul>
<a name="PD" id="PD">Complete Porter-Duff Support</a>
The <tt><a href=
"../../../api/java/awt/AlphaComposite.html">AlphaComposite</a></tt>
class provides alpha blending capabilities according to modes or
rules established by Porter and Duff. Out of the 12 rules that
Porter and Duff identified, the <tt>AlphaComposite</tt> API for the
SDK, version 1.3 defines and implements only 8 of them:
<ul>
<li>Clear</li>
<li>A (Src)</li>
<li>A over B (SrcOver)</li>
<li>B over A (DstOver)</li>
<li>A in B (SrcIn)</li>
<li>B in A (DstIn)</li>
<li>A held out by B (SrcOut)</li>
<li>B held out by A (DstOut)</li>
</ul>
For the SDK 1.4, <tt>AlphaComposite</tt> implements the
remaining 4 Porter-Duff rules:
<ul>
<li>B (Dst)</li>
<li>A atop B (SrcAtop)</li>

<li>B atop A (DstAtop)</li>
<li>A xor B (Xor)</li>
</ul>
<a name="TA" id="TA">Support for Checking if Font has a
Transform</a>
As of the SDK 1.2 the <tt><a href=
"../../../api/java/awt/Font.html">Font</a></tt> object has a
transform attribute that can be accessed with the <tt><a href=
"../../../api/java/awt/Font.html#getTransform--">Font.getTransform</a></tt>
method. You can perform geometric transformations, such as rotating
and shearing, on the <tt>Font</tt> by setting the transform
attribute. However, most applications use the Size attribute rather
than the transform to control the size and shape of characters. In
this case, the transform is a simple identity transform.
Currently, the only way to determine if the transform is an
identity transform is to call <tt>getTransform</tt> and inspect the
returned <tt>AffineTransform</tt>. Unfortunately, calling
<tt>getTransform</tt> requires the <tt>Font</tt> object to clone
the <tt>AffineTransform</tt> because the transform is mutable.
Two new methods in the SDK 1.4 allow you to check if a
<tt>Font</tt> object's transform is an identity tranform without
creating a new <tt>AffineTransform</tt>:
<ul>
<li><a href=
"../../../api/java/awt/Font.html#isTransformed--"><tt>java.awt.Font.isTransforme
d</tt></a>: 
Returns true if this <tt>Font</tt> object has a non-identity
<tt>AffineTransform</tt> attribute.</li>
<li><tt><a href=
"../../../api/java/awt/font/TransformAttribute.html#isIdentity--">java.awt.font.
TransformAttribute.isIdentity</a></tt>: 
Returns <code>true</code> if the wrapped transform is an identity
transform.</li>
</ul>
<a name="FE" id="FE">New Equality Methods for
FontRenderContext</a>
A <tt><a href=
"../../../api/java/awt/font/FontRenderContext.html">FontRenderContext</a></tt>
object encapsulates state about the graphics context and is used by
<tt>GlyphVector</tt> and <tt>TextLayout</tt>. Three new methods in
<tt>FontRenderContext</tt> allow you to compare the
<tt>FontRenderContext</tt> in the <tt>GlyphVector</tt> against the
one in the graphics context into which the <tt>GlyphVector</tt>
draws:
<ul>
<li><tt><a href=
"../../../api/java/awt/font/FontRenderContext.html#equalsjava.awt.font.FontRenderContext-">
equals(FontRenderContext)</a></tt></li>
<li><tt><a href=
"../../../api/java/awt/font/FontRenderContext.html#equals-java.lang.Object-">
equals(Object)</a></tt></li>
<li><tt><a href=
"../../../api/java/awt/font/FontRenderContext.html#hashCode--">hashCode()</a></t
t></li>
</ul>
These equals methods also have performance benefits because a
client does not have to create an <tt>AffineTransform</tt> to

perform an equality test. 
*As used on this web site, the terms "Java
Virtual Machine" or "JVM" mean a virtual machine for the Java
platform.


<div id="javasefooter">
<div class="hr">
<hr /></div>
<div id="javasecopyright">
<img id="oraclelogofooter" src=
"../../../images/oraclelogo.gif" alt="Oracle and/or its affiliates"
border="0" width="100" height="29" name=
"oraclelogofooter" />
<a href="../../../legal/cpyr.html">Copyright
©</a> 1993, 2015, Oracle and/or its affiliates. All rights
reserved.</div>
<div id="javasecontactus">
<a href=
"http://docs.oracle.com/javase/feedback.html">Contact
Us</a>
</div>
</div>


</body>
</html>

14 Features

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

14 Features

Caricato da

Copyright:

Formati disponibili

<?xml version="1.0" encoding="utf-8"?

with several implementation changes that:</p>

<li><tt>getDataElements(float[] normComponents, int normOffset,

commonly expected numeral shapes in most western countries.

<li>A atop B (SrcAtop)</li>

client does not have to create an <tt>AffineTransform</tt> to

Potrebbero piacerti anche