JSRs: Java Specification Requests
JSR 6: Unified Printing API (Java Print Service API)
Section 1: Identification
Section 2: Request
The target Java platform: All platforms that require a Java Print API.
Create a unified Java Print model and API that applies to all platforms with the recognition that the API may have proper subsets based on the requirement to support small footprint platforms, e.g. JavaCard. This unified Java Print model must support the requirements of the current Java 2 Print API as well as the to be developed Jini Print API and the requirements from the proposed Java Network Printing API.
Inappropriateness of existing specifications:
The Java 2 Print API requires the Java 2D package which Sun feels is unacceptable for small footprint platforms such as JavaCard. Rather than develop yet another Java Print API for small platforms, it is requested that a single Java Print model be developed that supports the current requirements of the Java 2 Print API, small footprint platforms as found in the To Be Developed Jini Print API, and the proposed Java Network Printing API.
The Specification to be developed and how it addresses the need:
This unified Java Print API will be based on a print model that meets the requirements of the current Java 2 Print API, Jini Printing, and the proposed Java Network Printing API. It will also contain an extensible attribute mechanism that will allow device manufacturers to add their own advanced feature sets. In addition it will use the job submission model of the new Internet Printing Protocol (IPP) 1.1 and the attribute names of IPP 1.1 as much as possible. Note that it is not a requirement to use the IPP 1.1 HTTP based protocol since wire protocols are out of scope for this API.
Detailed description of the underlying technology or technologies:
This unified Java Print API will leverage the work done for the released Java 2 Print API, the proposed Java Network Print API as well as the prototyping being done for Jini printing. In addition it will use the IPP 1.1 model wherever possible and appropriate.
Proposed package name for API Specification:
The requirement is to have one unified Java Print model. Currently there is the Java 2 java.awt.print package, the proposed Jini Print package and the Java Network Print API package. It is left to the participants as to whether a single package can be developed or whether there needs to be multiple packages to support the various target markets.
Possible platform dependencies:
Many Java Print API implementations rely on the native platform's underlying print system for user dialogs and print job creation/transport implementations. Consequently implementation of this API, for both the User Interface and print job emission components may or may not include native platform code.
The unified Java Print API will use the authentication, authorization, and confidentiality security features of the underlying print transport protocol. For example, if the underlying print transport protocol binds a "user" to a "job" then a cancel job operation should fail if a user tries to cancel someone else's job.
Internationalization and Localization implications:
This unified Java Print API will provide invocation methods for the classic "device selection" and "job control" dialogs but the actual look and feel and internationalization/localization of these dialogs is out of scope for this specification. These dialogs are often implemented by the native underlying print system.
Java's inability to print effectively has been cited by numerous major
vendors as a factor limiting deployment of Java applications. The goal
of this work is to develop a unified Java Print model that supports all
known requirements of Java 2, Jini printing, and the Java Network Printing
API with a generic extension capability for future needs. If this goal
is not achieved, Java will be adding additional incompatible API requirements
to the already overburdened print device manufacturers and Java application
writers which will impede acceptance of Java in these critical markets.
It is a goal of this work to be backwards compatible with the current Java 2 Print API. The participants will have to decide whether this is possible or not.
Existing specifications that might need revisions as a result of this work:
Section 3: Contributions
Detailed list of existing documents, specifications, or implementations that describe the technology:
The working group will first develop a set of requirements and use cases based on reviewing the existing and proposed Java Print APIs in conjunction with any new requirements from the participating companies. A unified Java Print model will be developed from these requirements which will provide the basis for the API design and reference implementation phase. The Java Community Process will be followed which will ensure that all industry requirements are met in a timely manner.