United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4285083 Add access to bidirectional text information
JDK-4285083 : Add access to bidirectional text information

Details
Type:
Enhancement
Submit Date:
1999-10-26
Status:
Closed
Updated Date:
2001-09-10
Project Name:
JDK
Resolved Date:
2000-10-25
Component:
client-libs
OS:
generic
Sub-Component:
2d
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.2.0,1.3.0,1.4.0
Fixed Versions:
1.4.0 (beta)

Related Reports
Duplicate:

Sub Tasks

Description

Name: jh34982			Date: 10/26/99



The Unicode Bidirectional Algorithm is is currently implemented in two
places, sun.awt.font and in javax.swing.text.  There should be one
public implementation in java.text.  Swing wants to use a public API
to get this information, and the duplication of code is undesirable.

The Unicode Bidirectional Algorithm analyzes text using the Unicode
character properties, and determines the direction of runs of the
text.  This is necessary to properly display Hebrew and Arabic text in
the correct order.

The current implementation is all Java, but it would be useful to have
efficient access from the native font code so that Hebrew and Arabic text
can be more efficiently rendered. We would use a native implementation
and provide Java access through JNI.  We have a C++ implementation
available.

The java.lang.Character class does not provide access to a character's
bidirectional property.  As Character is the interface for all Unicode
character information, it should be extended to add access to this
information for Java clients.  This is requested in bug 4132045.

======================================================================

                                    

Comments
EVALUATION

The simplest thing to do is make the current class public in java.text.  It has more API than we might want to expose, though, and the API may hinder changes to the implementation in the future.

Simplifying the API will require some changes to the clients (Swing and Java2D TextLayout) in places where they access the removed API.  These changes should be relatively few, however.

Wrapping native code has the advantages that the native code is more current and would be usable by java2d.  I've written the wrapper but have not completed testing on it-- this would take about a week.  The change to java2d to call the native code (instead of throwing an exception each time it is asked to render a Hebrew string, as happens currently) could be done at a later date.
doug.felt@eng 2000-04-25

Name: db100478			Date: 09/08/2000


Committing to merlin release


======================================================================
                                     
2000-04-25
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
merlin-beta

FIXED IN:
merlin-beta

INTEGRATED IN:
merlin-beta

VERIFIED IN:
merlin-beta3


                                     
2004-06-14



Hardware and Software, Engineered to Work Together