An attribute represents a printing feature that a print service can provide. For each attribute, a print service either does or does not support the attribute. For each possible value of a supported attribute, a print service either does or does not support the value.
The API requires every print service to support certain attributes; other attributes are optional and the service can choose whether or not to support them. Each attribute has a set of values that it accepts. The API requires every print service to support certain values for certain attributes; other attribute values are optional and the service can choose whether or not to support them. These support requirements are recorded in the documentation for each attribute class.
Package javax.print.attribute.standard contains standard printing attributes and standard printing attribute values that are widely used in the printing domain. A print service vendor can provide new vendor-specific printing attributes in addition to the standard ones. A vendor can also provide vendor-specific extensions (subclasses) of the standard printing attributes -- for example, to provide additional vendor-specific values for an existing standard attribute. Of course, if a vendor wants clients to be able to use any added or extended attributes, the vendor must publish the new attribute classes.
Many of the standard attribute classes extend one of the abstract syntax classes of the javax.print.attribute package. These abstract syntax classes each represent a different type. The EnumSyntax class, for example, represents a type-safe enumeration. The abstract syntax class provides a wrapper for the attribute value.
If an attribute class extends EnumSyntax, and the value of the
attribute is an IPP-compatible value, the attribute's toString
method returns the IPP string representation of the attribute value, such as
"processing-stopped" for the
JobState attribute. However, because the
EnumSyntax class is extensible, vendors can define their own
attribute values. If an attribute uses the EnumSyntax class
and is set to one of these vendor-defined values then the toString
method will not return the IPP string representation of the value.
A printing client application will typically not need to use all the printing attribute classes in package javax.print.attribute.standard, just the ones that pertain to the application.
The attribute classes in package javax.print.attribute.standard are based on the Internet Printing Protocol (IPP) attributes as defined in the Internet RFC document, RFC 2911 Internet Printing Protocol/1.1: Model and Semantics dated September 2000. See RFC 2911 for more information. The descriptive text for each attribute class was taken largely from the above documents. The above authors' contribution to the API is gratefully acknowledged.
Some attributes are doc attributes but not print request attributes and may only be specified at the doc level. Some attributes are print request attributes but not doc attributes and may only be specified at the Print Request level. Some attributes are both doc attributes and print request attributes and may be specified either at the doc level or at the Print Request level.
When specified at the doc level, an attribute applies just to that one doc. When specified at the Print Request level, an attribute applies to the whole job, including all the docs in the job. However, an attribute specified at the doc level overrides an attribute in the same category specified at the Print Request level.
Some attributes are both print request attributes and print job attributes; a client may include such attributes in a Print Request to specify characteristics for the ensuing Print Job, and those attributes then also appear in the Print Job's attribute set. Some attributes are print job attributes but not print request attributes; the print service itself adds these attributes to the Print Job's attribute set.
Please note: In the javax.print APIs, a null reference parameter to methods is incorrect unless explicitly documented on the method as having a meaningful interpretation. Usage to the contrary is incorrect coding and may result in a run time exception either immediately or at some later time. IllegalArgumentException and NullPointerException are examples of typical and acceptable run time exceptions for such cases.
@since 1.4