 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 226: Scalable 2D Vector Graphics API for J2METM
Updates to the Original Java Specification Request (JSR) The following information has been updated from the original proposal, as follows: 2015.04.13: The Maintenance Lead from Nokia Corporation has changed to Adamu Haruna. Maintenance Lead: Adamu Haruna E-Mail Address: adamu.haruna Telephone Number: - Fax Number: - 2012.08.22: The following section has been updated. 2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
TCK: 2012.08.21: North Sixty-One has become the co-Maintenance Lead. Maintenance Lead: Kimmo Löytänä E-Mail Address: jsr226 Telephone Number: - Fax Number: - 2009.06.24 The Maintenance Lead was changed to Juha Eskelinen. Maintenance Lead: Juha Ekselinen E-Mail Address: juha.eskelinen Telephone Number: - Fax Number: - 2009.03.06 The Maintenance Lead was changed to Jarmo Korhonen. Maintenance Lead: Jarmo Korhonen E-Mail Address: jarmo.j.korhonen Telephone Number: +358 7180 21022 Fax Number: +358 7180 70530 Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Nokia Corporation Name of Contact Person: Tolga Capin E-Mail Address: tolga.capin@nokia.com Telephone Number: +1 972 894 4651 Fax Number: +1 972 894 4589 Specification Lead: Tolga Capin & Suresh Chitturi E-Mail Address: tolga.capin@nokia.com & suresh.chitturi@nokia.com Telephone Number: +1 972 894 4651 & +1 972 894 6758 Fax Number: +1 972 894 4589 & +1 972 894 5937 Initial Expert Group Membership: * Nokia Corporation Supporting this JSR: * Nokia Corporation Section 2: Request
2.1 Please describe the proposed Specification:This specification will define an optional package API for rendering scalable 2D vector graphics, including image files in W3C Scalable Vector Graphics (SVG) format. The API is targeted for J2ME platform, with primary emphasis on MIDP. The main use cases for this API are map visualization, scalable icons, and other advanced graphics applications. The EG shall consider possibilities for subsetting from Java 2D API / JSR-209. Where subsetting is not possible, the API should be efficiently implementable on top of the Java 2D API / JSR-209. The API should be rich enough to support an SVG Tiny implementation. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The API is proposed to be an optional package to be used together with several J2ME profiles. Therefore, the design of the API should take into account support for both MIDP / LCDUI and PP/PBP / AWT as much as possible. This API will use floating point data types in the API methods in order to provide a clean and easy to use API. However, it should be possible to implement this API using fixed-point arithmetic underneath the API layer. Because floating point data types are used in the API, it requires CLDC 1.1 as the minimum configuration. The target footprint for this API including only the wrappers to native code should be under 30KB, assuming a level of support of native 2D graphics functionality on the device. 2.3 What need of the Java community will be addressed by the proposed specification?This specification will bring the following capabilities to the mobile terminals with J2ME/CLDC 1.1 support:
* Ability to load and render external 2D vector images, stored in the W3C SVG Tiny format. The API may be extendable to support other formats. 2.4 Why isn't this need met by existing specifications?Current proposals for integration of 2D into a Java environment are unsuitable for constrained devices due to ROM footprint, RAM size, or processing power requirements. They cannot be adopted as such for embedded devices. Instead, one must either design a new API that allows best interoperability with native graphics support, or define a subset of an existing API.
JSR-118 - MIDP2.0 - The LCDUI Graphics class under MIDP 2.0 is responsible for all the 2D graphics related features within the MIDP 2.0 Profile. However, there are some limitations in supporting advanced graphical features such as thick strokes, arbitrary shapes, affine transformation, etc. In addition, this API does not allow loading 2D vector graphics objects from external image files, such as SVG 2.5 Please give a short description of the underlying technology or technologies:There is an increasing demand for scalable 2D images that can adapt to devices with different terminal capabilities. Vector graphics is becoming the technology of choice for scalable image and animation representation on mobile devices. Vector graphics represents 2D content as geometric shapes: lines, rectangles, polygons, circles, smooth curves, and so on. In general, the advantages of vector graphics over raster graphics are:
* Animation - Vector graphics provides possibility of predefined animation and scripted animation (advantageous for writing games). * Interactivity - Vector graphics allows users to interact with content. * Searchability - Vector graphics allows the users to search for text in the image. For example, you can automatically find a street name on a map. Several applications have been identified for 2D vector graphics. Some applications require simple shapes to be rendered, while others require authoring complex images and animations in a 2D modeling/illustration tool, or generation of these images automatically from databases. These applications require a high-level interface to load, manipulate zoom/pan level, and render complex 2D vector graphics content. W3C has defined an open 2D vector graphics format, called SVG (Scalable Vector Graphics). SVG is an XML-based language, with three types of graphical objects: vector graphics shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. Objects can be animated declaratively or through scripting. SVG specification includes a DOM (Document Object Model) API to allow high-level manipulation of content. The target in this JSR is to provide a scalable and extensible API that allows displaying static and declaratively animated SVG Tiny Profile content and immediate 2D graphics rendering. The immediate mode gives the programmer the required flexibility of drawing directly to the canvas in order to achieve fast rendering, which eliminates the need to construct the DOM portion in the case of loading SVG content. The immediate mode part of the API should target to support the missing advanced 2D features in CLDC/MIDP. The API should attempt to maintain compatibility with LCDUI and AWT as much as possible. The high-level part of the API should allow loading and transforming static SVG Tiny content with minimal programming. The API should also support declarative animation of SVG content in retained mode. The approach to be taken in this JSR ensures timely delivery and a small footprint to match the short-term device requirements. The API should support:
* Low-level graphics primitives: The API should support 2D rectangles, circles, polygons, arbitrary shapes, text, and the ability to change their properties, such as transform and stroke properties. This part of the API will be the basis for a high-level API or Java applications that need low-level rendering (e.g. UI). * Graphics Overlay and Layering: The API should support overlaying of 2D objects on top of SVG Tiny content. It should also be possible to achieve layering by rendering multiple SVG Tiny images on top of one another. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)TBD 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?None known or anticipated. 2.9 Are there any internationalization or localization issues?International text/font support is system dependent. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?None known or anticipated. 2.11 Please describe the anticipated schedule for the development of this specification.Community Review Draft: Q3/2003 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.E-mail, teleconference, and face-to-face discussions as needed and as appropriate 2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The RI and TCK will be delivered as a stand-alone optional package for the J2ME platform. 2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).
2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.These terms only represent the initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Nokia at its sole discretion. For RI in source code form we will charge one time access fee, and annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to spec changes, and when made generally available by specification lead. Binary license is free of charge. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.In addition to the JSRs mentioned in Section 2.4, the following references may be applicable: 3.2 Explanation of how these items might be used as a starting point for the work.These items will be used for general reference purposes. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR. |
