Data processing: software development – installation – and managem – Software program development tool – Programming language
Reexamination Certificate
2001-05-01
2004-01-13
Chavis, John (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Programming language
C345S442000
Reexamination Certificate
active
06678881
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of two dimensional paths. More particularly, the invention relates to using and accessing path information maintained in multiple formats in an object oriented system.
2. Background Art
When drawing or printing to a display device or printer, an application developer uses a two dimensional path that is filled or stroked with a pen. A path consists of a combination of elements such as lines and curves. Rendering code is designed to handle certain formats of path elements (certain types of lines and curves), but some applications may want to specify their paths in an alternative format. In the prior art, an application that didn't understand a particular path format was unable to process and utilize that path. Thus, for a device or application to utilize a path, the developer was forced to specify the path in a standard form (in the standard form, only one type of curve segment exists, a Bezier curve segment) to the device directly. Consequently, only a limited set of recognizable paths could be used and customizable formats were not permissible. Such a format restriction is not flexible and limits the developer's use of numerous applications. A background of paths and object oriented systems is described below.
Paths
A path is a two dimensional (2D) trajectory on a drawing surface that can be filled or stroked with a pen. For example, the lines and curves that constitute a text character are paths. Each path may be broken down into a series of lines and curves. Referring to
FIG. 2
, the text character “R” is comprised of a series of lines and curves: line
201
-
204
; curve
201
-
202
; and line
203
-
205
. The combination of the line
201
-
204
, curve
201
-
202
, and line
203
-
205
constitute a path for the character “R”. The path may be in varying formats. A standard path format that is commonly used is a Bezier path. A Bezier path contains a combination of lines and Bezier curves. A Bezier curve is constructed by blending a set of control points to form a composite describing the curve. For example, referring to
FIG. 2
, points
201
,
206
,
207
, and
202
are control points used in constructing the Bezier curve
201
-
202
. Polynomial functions blend the four control points to result in the actual curve. Consequently, to construct a Bezier curve, a polynomial function accepts multiple control points and forms a composite function that describes the curve.
The method for developing a Bezier curve (and a resulting path) may not be used in all applications. For example, some applications may use a Spline curve or another customizable format. Further, there are formats that can be used to represent a path that don't translate directly into a rendering algorithm such as a format that might be used to edit a path in a drawing program. With such a format, the prior art forces the drawing program to edit the curve segments as Bezier segments and does not permit the drawing program to use its own format (which may use rational coordinates). Using its own format, the individual coordinates could be edited or transformed more rapidly and efficiently than performing the transform on the forced Bezier path.
To transform a path (e.g., rotate, scale, etc.), the prior art requires a specific type of transform and a specific type of path. The transform and an object that operates on the path expects this specific type of path. If there is more than one form, separate calls are made to transform the path from each of the different formats to the standard format (e.g., one call would render or transform one kind of path and another call would render or transform the other type of path). These calls would have to be enumerated in the object and may not be performed when the developer desires it.
The prior art limits developers to the use of a standard Bezier path. Other types of paths including custom paths must be transformed to a Bezier path prior to utilization by a developer. The lack of flexibility and inability to access and use multiple path formats at the developer's option necessitates the need for the present invention.
SUMMARY OF THE INVENTION
A path defines a two dimensional trajectory on a drawing surface that can be filled or stroked with a pen. Paths may be expressed in a plethora of formats. However, for an application to manipulate, transform or perform other operations on a path (e.g., rotate or scale the path), prior art requires the developer to specify the path in the standard format (a Bezier path). Such a limitation prohibits drawing programs or developers from fully utilizing their artistic ability to create paths in unknown or custom formats.
One or more embodiments of the invention provide the ability to use multiple path formats. A path is stored in an arbitrary format that is often unrecognizable in various applications. One or more embodiments provide the path with the ability to translate itself into a recognizable format. A variety of applications can then use the path's translation ability to perform desired operations after it is determined whether the transform may be performed on the path or not.
For example, in one or more embodiments, each path object maintains the ability to translate itself into a Bezier path format and return a new path object in the Bezier format. Consequently, when the application determines that the transform may not be performed on the path (i.e., it does not recognize the path), it simply requests the path object to translate itself and return the Bezier Path object. The transform or other operation is then performed on the Bezier Path object.
In another example, one or more embodiments of the invention provide for the paths to be viewed as shapes and stored in instances that implement a Shape Interface. In addition, iterators are defined that have the ability to iterate over each segment of the path (in the Shape object) and perform transforms or other operations one segment at a time. Thus, when it is determined that the transform may not be peformed on the path (i.e., the path format is unrecognizable by the application that desires to perform the transform or other operation), an iterator object is retrieved. The iterator retrieves one segment of the shape at a time (and may convert it into a Bezier format) and allows the transform or other operation to be accomplished on the segment. In this manner, the transform or other operation may be applied to the entire shape, one segment at a time, on the fly, without translating the entire path at once into a Bezier Path.
Many applications may use a path's ability to translate itself into a recognizable format. For example, in one or more embodiments an application may desire to perform a transformation of the path. The transformation ability is provided by the implementation of a Transform Interface. When the application desires to perform a transformation, the transform determines if it understands the path format (i.e., is the path in a recognizable format). If the path is recognizable, the transform is performed directly on the path. If the path is not recognizable, it asks the path to transform itself into a recognizable format. The operation may then be performed on the recognizable format returned (e.g., a BezierPath format or a PathIterator).
One or more embodiments of the present invention provide a path with the ability to perform a transform to its points directly. In one or more embodiments, a two stage negotiation process utilizes this ability and permits a desired operation to be performed on a path in its initial format. In the first stage, the path determines if it recognizes the transform or other operation. If it does, then the path performs the transform or other operation itself. If the path does not understand the transform or other operation, in the second stage the path requests the transform or other operation to perform the desired operation. The transform or other operation then determines if it recognizes the path. If it does, the
Chavis John
Martine & Penilla LLP
Sun Microsystems Inc.
LandOfFree
Representing a path as an object with transformation capability does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Representing a path as an object with transformation capability, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Representing a path as an object with transformation capability will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3185836