Интерфейс Doc

public interface Doc

Интерфейс Doc определяет интерфейс для объекта, предоставляющего один фрагмент данных печати для задания печати. "Doc" - это короткое, легко произносимое слово, означающее "фрагмент данных печати". Клиент передает заданию печати объект, реализующий интерфейс Doc, а задание печати вызывает методы этого объекта для получения данных печати. Интерфейс Doc позволяет заданию печати:

• Определить формат или «тип данных» (класс DocFlavor), в котором доступны данные печати. Тип данных указывает формат данных печати (тип MIME) и класс представления объекта, из которого берутся данные печати.
• Получить объект представления данных печати, который является экземпляром класса представления типа данных. Затем задание печати может получить фактические данные печати из объекта представления.
• Получить атрибуты печати, которые указывают дополнительные характеристики данных или задают инструкции обработки, которые должны быть применены к данным. Атрибуты печати определены в пакете javax.print.attribute. Данные возвращают свои атрибуты печати, сохраненные в наборе атрибутов javax.print.attribute.DocAttributeSet.

Каждому методу в реализации интерфейса Doc разрешается всегда возвращать один и тот же объект каждый раз при вызове метода. Это имеет последствия для задания печати или другого вызывающего объекта, чья область представления данных "потребляет" данные печати при получении данных вызывающим объектом, например, объект представления данных, являющийся потоком. После того как задание печати вызвало getPrintData() и получило поток, любые последующие вызовы getPrintData() вернут тот же объект потока, чтение из которого может уже проходить, а не новый объект потока, который повторно прочитает данные печати с начала. Указание объекта данных таким образом упрощает реализацию объектов данных и оправдывается тем, что определенные данные предназначены для передачи данных печати только одному заданию печати, а не нескольким различным заданиям печати. (Чтобы передать одни и те же данные печати нескольким различным заданиям печати, необходимо создать несколько различных объектов данных поверх одного и того же источника данных печати.)

Интерфейс Doc предоставляет значительную гибкость реализации. Данные печати могут уже существовать при создании объекта данных. В этом случае объекты, возвращаемые методами данных, могут быть переданы в конструктор данных, сохранены в данных заранее и просто возвращены при вызове. В качестве альтернативы данные печати могут еще не существовать при создании объекта данных. В этом случае объект данных может предоставить "ленивую" реализацию, генерирующую объект представления данных (и/или данные) только тогда, когда задание печати запрашивает их (когда задание печати вызывает метод getPrintData()).

Нет ограничений на количество клиентских потоков, которые могут одновременно обращаться к одним и тем же данным. Поэтому все реализации интерфейса Doc должны быть спроектированы для многопоточной безопасности.

Однако может быть только один потребитель данных печати, полученных из Doc.

Если данные печати получаются от клиента как поток, вызывая методы Doc getReaderForText() или getStreamForBytes(), или потому, что источник данных печати уже является InputStream или Reader, то служба печати должна всегда закрывать эти потоки для клиента при всех условиях завершения задания. При следующем замечании. Если данные печати сами по себе являются потоком, служба всегда закроет его. Если данные печати — это что-то другое, что можно запросить как поток, служба закроет поток только в том случае, если она получила поток перед завершением. То есть, то что служба печати может запросить данные как поток, не означает, что она это сделает, с последствиями, что реализаторы Doc , которые полагаются на службу для их закрытия, должны создавать такие потоки только в ответ на запрос со стороны службы.