/*
 * @(#)Doc.java	1.8 05/11/17
 *
 * Copyright 2006 Sun Microsystems, Inc. All rights reserved.
 * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 */

package javax.print;

import java.io.InputStream;
import java.io.IOException;
import java.io.Reader;
import java.io.UnsupportedEncodingException;

import javax.print.attribute.AttributeSet;
import javax.print.attribute.DocAttributeSet;


/**
 * Interface Doc specifies the interface for an object that supplies one piece 
 * of print data for a Print Job. "Doc" is a short, easy-to-pronounce term     
 * that means "a piece of print data." The client passes to the Print Job an
 * object that implements interface Doc, and the Print Job calls methods on
 * that object to obtain the print data. The Doc interface lets a Print Job: 
 * <UL>
 * <LI>
 * Determine the format, or "doc flavor" (class {@link DocFlavor DocFlavor}),
 * in which the print data is available. A doc flavor designates the print 
 * data format (a MIME type) and the representation class of the object
 * from which the print data comes. 
 * <P>
 * <LI>
 * Obtain the print data representation object, which is an instance of the  
 * doc flavor's representation class. The Print Job can then obtain the actual
 * print data from the representation object.
 * <P>
 * <LI>
 * Obtain the printing attributes that specify additional characteristics of  
 * the doc or that specify processing instructions to be applied to the doc. 
 * Printing attributes are defined in package {@link javax.print.attribute 
 * javax.print.attribute}. The doc returns its printing attributes stored in 
 * an {@link javax.print.attribute.DocAttributeSet javax.print.attribute.DocAttributeSet}. 
 * </UL>
 * <P>
 * Each method in an implementation of interface Doc is permitted always to 
 * return the same object each time the method is called.
 * This has implications 
 * for a Print Job or other caller of a doc object whose print data 
 * representation object "consumes" the print data as the caller obtains the 
 * print data, such as a print data representation object which is a stream. 
 * Once the Print Job has called {@link #getPrintData() 
 * <CODE>getPrintData()</CODE>} and obtained the stream, any further calls to 
 * {@link #getPrintData() <CODE>getPrintData()</CODE>} will return the same 
 * stream object upon which reading may already be in progress, <I>not</I> a new 
 * stream object that will re-read the print data from the beginning. Specifying 
 * a doc object to behave this way simplifies the implementation of doc objects, 
 * and is justified on the grounds that a particular doc is intended to convey 
 * print data only to one Print Job, not to several different Print Jobs. (To 
 * convey the same print data to several different Print Jobs, you have to 
 * create several different doc objects on top of the same print data source.) 
 * <P>
 * Interface Doc affords considerable implementation flexibility. The print data 
 * might already be in existence when the doc object is constructed. In this 
 * case the objects returned by the doc's methods can be supplied to the doc's 
 * constructor, be stored in the doc ahead of time, and simply be returned when 
 * called for. Alternatively, the print data might not exist yet when the doc 
 * object is constructed. In this case the doc object might provide a "lazy" 
 * implementation that generates the print data representation object (and/or 
 * the print data) only when the Print Job calls for it (when the Print Job 
 * calls the {@link #getPrintData() <CODE>getPrintData()</CODE>} method). 
 * <P>
 * There is no restriction on the number of client threads that may be 
 * simultaneously accessing the same doc. Therefore, all implementations of 
 * interface Doc must be designed to be multiple thread safe. 
 * <p>
 * However there can only be one consumer of the print data obtained from a
 * Doc.
 * <p>
 * If print data is obtained from the client as a stream, by calling Doc's
 * <code>getReaderForText()</code> or <code>getStreamForBytes()</code>
 * methods, or because the print data source is already an InputStream or
 * Reader, then the print service should always close these streams for the
 * client on all job completion conditions. With the following caveat.
 * If the print data is itself a stream, the service will always close it.
 * If the print data is otherwise something that can be requested as a stream,
 * the service will only close the stream if it has obtained the stream before
 * terminating. That is, just because a print service might request data as
 * a stream does not mean that it will, with the implications that Doc
 * implementors which rely on the service to close them should create such
 * streams only in response to a request from the service.
 * <P>
 * <HR>
 */
public interface Doc {

    /**
     * Determines the doc flavor in which this doc object will supply its
     * piece of print data. 
     *
     * @return  Doc flavor.