AdobePostScriptExtreme"
`
`_____
`Adobe Solutions for Commercial Printing
`Since its introduction in 1984, the Adobe PostScript language has not only been the mainstay of desktop
`publishing in the commercial print world, but it has become the standard for digital commercial graphic arts
`production. Adobe Systems is constantly improving the capabilities of the PostScript language and its output
`systems as the market for digital communications grows. These extensions have covered a multitude of im-
`provements, including color management, image manipulation, memory management, dictionaries and
`caches, compression, forms, filters, device controls, composite fonts, and much more. But companies under
`pressure in the commercial environment must integrate more than a superset of excellent features. Workflow
`management and process automation can optimize production and manufacturing. Adobe has extended the
`capabilities of the PostScript language to create its most advanced, flexible, scalable, and productive imple-
`mentation: Adobe PostScript Extreme software.
`
`Adobe PostScript Extreme technology is an architecture of related modules whose functionality optimizes
`throughput for commercial printing. Extreme makes use of three of Adobe's complementary core technolo—
`gies: Adobe PostScript 3'“ interpreters, Portable Document Format (PDF), and Portable Job Ticket Format
`(PJTF). There are two variants of Extreme: Extreme for Graphic Arts and Production Printing, and Extreme
`for High Volume Printing. This paper focuses on Extreme for Graphic Arts and Production Printing. How—
`ever, the ultimate goal of both versions of Extreme is to provide a robust job management environment for
`commercial printing.
`
`Understanding the Adobe PostScript Extreme architecture and modules is important to understanding how
`Extreme will create new flexibility and open extensibility for long—term workfiow management solutions.
`This white paper discusses the foundations of Adobe PostScript Extreme, the modules that form its architec—
`ture, its near—term benefits, and its long-term vision. The discussion will be broken into two parts: an over—
`view of the features and benefits of Extreme and a technical discussion. which provides practical information
`
`for system planning and development.
`
`Architecture overview
`
`Adobe PostScript Extreme consists of three major components:
`
`0 Extreme: a set of process modules and a communication framework for queuing these processes and
`automating/coordinating the transfer of data from process to process
`
`0 PDF: a page independent, reliable digital master to deliver content
`
`° PJTF: a companion standard to PDF used as a control mechanism
`
`Extreme process modules are known as Job Ticket Processors (JTP). JTPs get information from a Job Ticket,
`which is an extended set of processing information about a PDF document written in Portable Job Ticket
`Format, which is based on the PDF language. A Job Ticket may be included in a PDF document or exist as a
`
`separate entity. A PDF document and its associated Job Ticket contain essentially all the information (con—
`tent, graphics, production specs, etc.) required for viewing, processing, and outputting a file in a self~con~
`tained package. Because a PDF document contains this key information, it can be thought of as a Digital
`Master, a complete and reliable description of a file's content and processing requirements.
`
`JTPs provide independent functionality—in other words, they do things. There are different types of JTPs
`that are called into play by the specifications contained in the Job Ticket. Modular Job Ticket Processors
`
`provide a way to “mix—and—match” required steps from an inventory of functionality. For example, the
`trapping engine (mechanism) is a JTP, imposition is effected by a JTP, and even output is handled by an
`output JTP.
`
`PETITIONERS EX. 1013, p. 1
`
`’ ‘0!
`‘
`Adobe
`
`PETITIONERS Ex. 1013, p. 1
`
`

`

`ln Extreme, JTPs can be sequenced flexibly so that if differentjobs require different manufacturing plans,
`the same system can be used to structure the required processing sequences.
`
`Underneath it all, the communication framework of Extreme has a Coordinator, which sends information to
`
`and receives information from the JTPs. The Coordinator passes instructions between the JTPs. The Coordi—
`nator contains a Sequencer that defines the internal Extreme workflow. The Sequencer reads information
`from Job Tickets, sets up a JTP sequence, makes process choices, and then updates Job Tickets as information
`is returned from each JTP. Thus rather than being a hard-wired flowchart of steps, the process itself becomes
`much more flexible and responsive to the real—time results of the processing. The other parts of the Extreme
`framework will be discussed in the second part of this white paper.
`
`A PDF file is the Digital Master of the job information. It includes the objects that collectively make up the
`document's content and the Job Ticket as a collection of history, information, and instructions about the
`
`production and processing requirements. PDF documents contain everything required for commercial out—
`put. All the resources needed are self—contained in a way that significantly improves the PostScript to print
`workflows because a PDF file contains a vastly expanded amount of information pertaining to viewing, pro-
`
`duction, and output. With a PDF file as a Digital Master, Adobe PostScript Extreme uses the master informa
`tion to create workflow automation and assure reliable processing. There is a more extensive discussion of
`
`PDF Digital Masters later in this paper, and for more information, Adobe also has a white paper entitled
`"Preparing Adobe PDF files for High Resolution Printing" that can be found on Adobe's Web site at
`www.adobe.com.
`
`Portable Job Ticket Format is the language of the Job Ticket and is used for processing information. PJTF
`extends the functionality of PDF by carrying history, instructions, and process control about both the con—
`tent and the document itself. A Job Ticket collects information about the state of the document and what
`
`needs to happen to it. This information is passed to the Coordinator, which determines which Job Ticket
`Processors are required. The JTPs then effect the required processing and pass the document to the next part
`of the sequence. A Job Ticket is an independent part of a PDF document, and by separating the processing
`information from the content, a Job Ticket becomes an unambiguous job process management tool. The Job
`Ticket knows what needs to be done, and the Job Ticket Processor knows how to do it. One important benefit
`to this structure is that Portable Job Ticket Format and Job Ticket Processors can both be independently
`
`extended as new processing technology evolves and as business markets expand.
`
`In summary, Adobe PostScript Extreme is a process management backbone that receives a PDF Digital Mas-
`ter file and processes it according to the job requirements. The backbone itself is extensible, and the processes
`can be automated in a way that has not been possible up to this point in time.
`
`Extreme benefits
`
`Graphic arts production is moving rapidly toward a completely digital workflow. The obvious benefits of
`digital workflow have been discussed widely throughout the industry and include flexible processing and
`repurposing of content as well as enhancements of precision digital output on devices that range from desk—
`top color inkjet printers to computer—to—plate machines. There are, however, other potential advantages to
`all—digital production that have been awaiting a system like Adobe PostScript Extreme.
`
`Workflow automation
`
`Prepress is a progressive process, and Adobe PostScript Extreme technology is ideal for sequencing the re—
`quired steps and managing the results. As a PDF document is built and moves through its required processes,
`information about these processes can be specified and collected in its Job Ticket. The Job Ticket can be
`examined, edited, and enhanced. In an Extreme environment, the Job Ticket Processors can act on this infor—
`
`mation and, in turn, pass these specifications (or new specifications) over to other Job Ticket Processors. A
`Job Ticket is also an audit trail of what has happened along the way, and it is possible to use this information
`
`to configure JTPs for following steps. By collecting data in the Job Ticket, there is much less confusion about
`what has happened and what remains to be done to the elements of the document. Thus, a PDF Digital Mas—
`ter becomes a self—contained, flexible blueprint of its future processing, no longer dependent on system configu—
`rations that may be inappropriate. This allows jobs to be processed dependably with little human intervention.
`
`PETITIONERS EX. 1013, p. 2
`
`PETITIONERS Ex. 1013, p. 2
`
`

`

`Flexible editing and updating
`
`A second advantage Extreme makes possible is the ability to make significant changes to the content and
`associated production instructions much later in the process. It is not necessary to return to the original
`applications to make and effect these changes, so an enormous amount of time is saved. This is a tremendous
`workflow improvement. One example of this might be a reprint of a four—color print job where budget con-
`siderations force the use of a lower quality paper than in an earlier run. Dot gain compensation of images
`should be adjusted because of the change in paper quality. A lower halftone screen is now necessary, so the
`amount of trapping required for artwork must be changed. Before Extreme. dot gain and trapping informa—
`tion would have been hardwired into the data, and these corrections would have had to be made image by
`
`image, artwork by artwork back in the native applications. But in an Extreme environment, these prepress
`specifications are contained in the Job Ticket, and only applied to the data when required at output time.
`Thus the content is kept in a more "generic" form until much later in the process, and can be targeted to a
`variety of different kinds of output much more flexibly. It's a direct byproduct of the modularity of Extreme
`and the integration of PDF and PJTF.
`
`Extreme has been a natural evolution based on the composite experience of the graphic arts industry.
`Workflows and responsibilities have undergone re—creation and re-evaluation, and the features and capabili—
`ties of Adobe PostScript software have been steadily improved. PostScript Level 2 added many of the capa—
`bilities mentioned in this paper's introduction. PostScript 3 software brings additional output capabilities,
`such as smooth gradients and key workflow enhancements—like the ability to use native PDF files.
`
`Adobe PostScript Extreme is here today, and its modular architecture has already spawned a number of
`differentiated systems that provide specific value-added enhancements. Equipment manufacturers and ven—
`dors can customize Extreme to create distinct implementations for different market requirements. For ex—
`
`ample, Extreme systems have an integrated ability to create PDF and use Acrobat” tools to edit and enhance
`the document before it is submitted for printing. Other systems add tool sets for imposition, trapping and
`output control within the print application or utility. Even more highly sophisticated systems add the ability
`to manage a distributed prepress environment in which the look and feel is that of a job manager sending
`groups of pages for ongoing processing.
`
`Native PDF creation
`
`Another key benefit of Extreme is its ability to create PDF directly. If an application that does not create PDF
`directly is the source of the pages, a reliable PDF Digital Master can be achieved because Extreme allows
`PostScript to be submitted for background conversion into PDF. This makes it easy for a job to be con—
`structed from different sources and have its print parameters captured simultaneously. Once in Extreme, the
`content of the pages is represented in PDF, and its associated production information is managed within the
`Job Ticket. The content and its production information can therefore be handled in a unified way from
`within the Extreme system.
`
`Different configurations of Extreme systems
`If a PDF document is the Digital Master of the future. then the Adobe PostScript Extreme architecture is the
`future of output. Equipment manufacturers will be able to configure Extreme in a variety of ways to provide
`functionality appropriate to different market requirements. Some examples of different systems that may be
`implemented by Extreme OEMs and system vendors follow below.
`
`Example 1: Direct PDF handling
`
`Some Extreme products will create PDF natively and transparently from a client (application) connected to
`a PostScript 3 RIP. This will allow the PDF to be submitted directly for output. Users can continue to work
`in familiar applications, and then submit files for processing in a familiar workflow. The obvious benefit of
`this is that the mistakes people make in creating complex PostScript files can be corrected from within the
`print application using familiar Acrobat tools instead of returning to the application to correct them.
`Within an Extreme system, PDF becomes more thanjust a carrier of information. It is viewable and
`editable. The value of working in PDF extends even further because it can also be used as a tool for
`proofing, preflight, and page re-ordering.
`
`PETITIONERS EX. 1013, p. 3
`
`PETITIONERS Ex. 1013, p. 3
`
`

`

`Example 2:A print application workflow
`Other products will have a print application that creates and describes the print job in terms of its process—
`ing requirements. These products receive page content from multiple locations, possibly at different times,
`and collect these disparate pieces into a unifiedjob. Thisjob will be represented by a single Job Ticket to
`describe the imposition, trapping, and rendering characteristics of the job. After the parameters are as—
`signed, the work can be sequenced, batched, and automated as necessary. By managing the disparate con—
`tent as a unified job, it is easier to coordinate the change to an all digital workflow using content and
`commercial data management.
`
`Example 3:A distributed workflow
`There will be products with an array of Job Ticket Processors distributed throughout a given workgroup. The
`JTPs will perform tasks like imposition, trapping, preflighting, and color correction directly on page content.
`These JTPs will control and manage the prepress system completely from within the Extreme architecture. By
`continuously building and extending the documents' Job Ticket (5), the document will become at once a
`Digital Master ready for print, and a complete log of the tasks performed and actions taken along the way.
`Therefore, job management becomes a reality. This type of Extreme system will present different personnel
`with different access to the information they need to schedule, track, verify the processing, and validate the
`quality of the job as it progresses. Additionally, the ability to audit for costing and billing also becomes im—
`plicit in this system.
`
`Example 4: Production printing
`
`Some printing environments do not need the processing complexity of the full prepress environment. Speed
`is the critical factor, and these businesses simply need to guarantee that every page will print and that their
`machines will run at full capacity. Extreme for High Volume Printing, a simpler implementation, will enable
`this by employing multiple RIPs to keep up with the output engines. Jobs will be split into individual pages
`that are then distributed to the RIPS on a "next bus out" basis, that is, whichever device is ready will get the
`
`next portion of thejob. Much like the read/write heads of a RAID storage device, there will be a minimum of
`“inactive" time. The Extreme system is “in charge" of the workflow: by performing tasks like preflighting and
`color correction long before the data arrives at the print engine, costly mistakes that today are often only
`found late in the production cycle are avoided. This means that like other Extreme systems, this one has
`built—in capabilities that guarantee every page will print and print at the output engine's rated speed.
`
`Future directions
`
`From a technological perspective, Adobe PostScript Extreme has been designed for a future of extensibility. It
`has an open architecture that third—party developers can use to create their own Job Ticket Processors as well
`as other components that will fit easily into its architecture. This means that as new technologies enhance
`graphic arts production, Extreme technology will adapt to the new environment. Further advances in the
`renderer will enable the consumption of CEPS file formats, multiple engine support, and better integration
`with asset management systems.
`
`Additions to the architecture of Extreme will enable integrated export of wholejobs for repurposing in dif»
`ferent media like the World Wide Web or alternative printing applications. But more importantly, because
`Extreme is an Adobe product, Extreme is guaranteed to be compatible with all future versions of PDF and
`PostScript as they evolve and become available.
`
`From a workflow perspective, Adobe PostScript Extreme will permit an ever expanding range of domains to
`be included in the flow of information. Through Portable Job Ticket Format, a job scheduling system can
`receive from and supply information to Extreme. Cost and billing systems can also be informed on the basis
`of actual production.
`
`The Adobe PostScript Extreme framework will provide major improvements for today's workflows and an
`extensible pathway toward ongoing development and growth. The enhancement of interpreters, extensions
`of PDF, and creation of an architecture that is not limited to today's technology are the keys to a system with
`real longevity in the graphic arts production environment.
`
`Since the introduction of Extreme, some of its original concepts have been enhanced, This has resulted in
`
`changes in functionality for some of the modules of Extreme. In the second half of this white paper, aspects
`of the architecture of Adobe PostScript Extreme are more closely examined. There is also new vocabulary to
`
`PETITIONERS EX. 1013, p. 4
`
`PETITIONERS Ex. 1013, p. 4
`
`

`

`learn: Job Tickets, Job Ticket Processors, Normalizers, Coordinators, and more. This information will be
`
`especially interesting to those involved with workflow engineering or systems planning. Others who want a
`look at some of the underpinnings of Adobe PostScript Extreme will also find the technical discussion that
`follows valuable.
`
`Technical overview
`
`PostScript 3
`Extreme is enabled by the evolution of Adobe PostScript 3 technology. Output has been improved with
`PostScript 3 in several important ways. Some of these improvements include better blends through the use
`of smooth shading operators, selectable separations, in—RIP trapping capability for separations, l-li—Fi color
`capabilities, and most importantly, direct printing of PDF. The ability of a PostScript 3 RIP to accept PDF
`directly opens the door to the adoption of Extreme workflow. Companies can begin to re—target their own
`production even before they own full Extreme systems by first acquiring PostScript 3 interpreters for their
`output devices and then converting their document base into PDF Digital Masters.
`
`The “generic" Extreme workflow
`Although there are different configurations of Extreme systems, it is possible to understand the workflow by
`following the progress of a specific job as it moves through Extreme. A retail mail order catalog, for example,
`contains all the elements of most graphic arts jobs. The content elements are text, graphics, and scans. The
`production elements include color management, trapping, and imposition. Pages are designed and con—
`structed during the layout phase. In this scenario, two different workgroups use different page—layout soft—
`ware. The first group's software creates PDF directly, and the second group's software can generate PostScript
`output. The entire job is targeted for first appearance on the company's Web site, and then to be followed
`with a commercial print run. Because the pages are to appear on the Internet, the scans have been created as
`RGB data.
`
`As the job is submitted to Extreme for prepress processing, the PostScript pages are distilled into PDF and
`stored in the page store. PDF pages are submitted directly to the Page Store. The Sequencer reads the Job
`Ticket, assigns tasks, and creates the logical flow for processing. The PDF pages are collected to a job that
`holds them for further processing as required. The Sequencer then manages the job by queuing pages for
`specific tasks (converting from RGB to CMYK in the color management JTP, trapping in the trapping JTP,
`and creating an imposition template in the imposition JTP). At each stage, the results are examined by the
`Sequencer to collect updates to the Job Ticket if required. Finally, the pages are sent for final assembly and
`rendering for output by the printer JTP.
`
`The Extreme printer JTP
`Extreme uses a highly optimized renderer within its architecture to take advantage of the efficiencies of a
`workflow system. This specially licensed component of Adobe PostScript Extreme is designed to ”consume"
`a PDF file and its Job Ticket. Natively consuming Job Tickets means that last minute corrections can truly be
`last minute or even last second. A page on a flat can be changed, or the layout of the flat itself can be
`changed—it doesn't matter until the actual submission for print. Even page content can change up to the
`very last second. The renderer can be directly linked to the workflow components upstream. This means
`much higher productivity for the actual rendering device.
`
`Extreme architecture
`
`When Adobe PostScript Extreme was first introduced to the industry, the first demonstrations were targeted
`to an audience that was primarily concerned with high—speed print production. The initial architecture was
`intended to serve very fast RlPing of black and white pages. The issue raised was how to output more pages
`more rapidly, and the enabler was PDF. This implementation is now called Adobe PostScript Extreme for
`High Volume Printing, and its architecture includes the ability to ”digest" PDF directly, as well as to take
`PostScript and convert it to PDF with the Normalizer. The workflow is optimized for high—speed printing
`with converted PDF pages delivered in order to the set of renderers driving the output engine. Little prepro-
`cessing is needed prior to rasterization, and speeds greater than 650 pages per minute can be achieved in
`commercial applications.
`
`PETITIONERS EX. 1013, p. 5
`
`PETITIONERS Ex. 1013, p. 5
`
`

`

`For other graphic arts environments, the requirements are more varied and detailed. What really differentiates
`Extreme from other systems today is that its architecture can encompass an entire workflow system, not just
`function as a high-volume output device. Therefore, in the implementation called Extreme for Graphic Arts and
`Production Printing, some conceptual and engineering changes have been made to Extreme's components.
`
`When viewed from a systems perspective, Extreme has three major parts: the controls (PJTF and Job Tickets).
`the message queuing and status protocol between JTPs (Extreme Communication), and the data (PDF con»
`tent). Based on thejob requirements and contents of the PDF, a Job Ticket is a multi—thread database that is
`passed by the Coordinator from JTP to JTP as required. It is the JTPs that get the work done.
`
`The Value of JTPs
`
`The JTP is the smallest working unit in the Extreme architecture. When components are added or removed
`from an Extreme system, they are in the form of a JTP. The most important JTPs are the Sequencer, Coordi—
`nator, Normalizer, and Renderer (or printer JTP). Together, these JTPs form the essential pieces of the
`architecture to:
`
`Interpret PostScript into PDF
`
`Gather the job together into the Page Store for processing
`
`Set up the processing sequence of JTPs
`
`Manage the pages through the JTP sequence
`
`Deliver the job to the printer JTP for rendering
`
`There are two categories of JTPs—those written by Adobe and those written by our licensed equipment
`manufacturers and ISVs. Of those written by Adobe, some are essential to any Extreme system (Sequencer,
`Normalizer, PJTP), and others are optional for an OEM to implement. The JTPs written by an OEM are what
`differentiate one vendor's product from another. Adobe OEMs typically add their value by implementing
`additional workflow components and by creating the user interface that ties the system together. Thus, the
`collection of JTPs in an Extreme system will vary with each specific equipment manufacturers implementa—
`tion. Adobe will continue to add value to the architecture by building components that integrate core tech—
`nology pieces into the existing core product offering.
`
`An architecture of JTPs permits distributed processing of PDF pages because of PDF's page independence.
`This means that many tasks can be accomplished simultaneously. Additionally, different processing sequences
`may be required for different jobs. Thus, if different jobs require different manufacturing plans, the same
`system can be used to structure the required processing sequences. Extreme enables batch processing by
`queuing up jobs to a single JTP. Therefore no scripting is necessary, only the correct process specification.
`
`The use of Job Ticket Processors has another very important benefit: Adobe PostScript Extreme is an open
`architecture. Today's prepress tools can be used along with tomorrow's enhancements. If a new process be—
`comes part of the graphic arts workflow, the JTP architecture is available so that the inventory of functional—
`ity can be expanded. By making the JTP structure available to third parties, Adobe has created a way for
`workflows to be enhanced without having to change the entire system. Adobe will encourage third—party
`developers and vendors to participate in the implementations of today and tomorrow.
`
`Extreme Communication
`
`Extreme Communication is a part of the architecture that is used internally to handle the messaging between
`JTPs throughout the architecture. Extreme Communication is an essential part of an Extreme system and is
`written by Adobe. The unit of information that is passed from JTP to JTP is the current job's Job Ticket.
`Extreme Communication facilitates the transmission of Job Ticket information and works behind the scenes
`
`to enable the different components of an Extreme system to communicate properly with each other.
`
`PJTF and Job Tickets
`
`With Portable Job Ticket Format, the process control is carried in a package, the Job Ticket, which is separate
`from the content. PJTF allows all the process steps to be specified within the Job Ticket. The process steps
`may be executed asynchronously, or in parallel, and for some processes like imposition, trapping and separa—
`tions, this allows the decisions required to be made where they belong—in production instead of at the time
`the PostScript file was created. This is called late binding. It is advantageous to wait as long as possible
`
`PETITIONERS EX. 1013, p. 6
`
`PETITIONERS Ex. 1013, p. 6
`
`

`

`because once these decisions are made, it is usually only possible to direct the content toward one type of
`output. But with late binding, content can be left in its most flexible form so that it can be output in a variety
`of ways to suit the needs of the market.
`
`With the ability to carry process specifications in PJTF, a new degree of process automation is enabled. Up to
`now, we have had to assemble information about the content and then manually intervene to make produc—
`tion decisions, although there have been some mechanisms to create limited process automation in the in—
`dustry. What makes Extreme different is that the architecture allows information that comes from content
`management to be taken into consideration for the decisions required by process management. PJTF pro—
`vides a link between the form content takes and the output (or manufacturing) requirements.
`
`The Job Ticket model has several significant aspects with varying degrees of freedom. The first is the data
`model, or what the object types and composite data types are. The Job Ticket and PJTF are presently based
`on the PDF specification. This allows a wide range of data types including strings, arrays, and dictionaries, in
`addition to the obvious data types related to content. The PDF specification is fully public.
`
`The second aspect is the data representation or how the data types are packaged and presented. It is highly
`likely that as Extreme systems are configured for flexible multipurposing of content, file formats other than
`PDF will co-exist. For example, XML and Java representations may be requirements for a system in which
`content for printing and electronic commerce must interrelate. Data might be represented in an object—
`oriented database that enhances the Extreme system's ability to manage document content more flexibly.
`The ability to represent data flexibly is an important part of the Extreme system's open architecture.
`
`The third aspect is the data dictionaries, or what the classes of data that will be manipulated in an Extreme
`system are. Data that doesn't belong in the main specification but is important to a particular segment of the
`industry might be included as a public or private data dictionary—for example—information extensions
`proposed by an interested industry group such as CIP3 (Cooperation in Prepress, Printing, and
`Postprocessing). These CIP3 extensions would be used to manage information specific to the printing manur
`facturing process, which could optimize the workflow throughout.
`
`Digital Master advantages
`In a cross—platform, cross-application environment, there will always be differences in the way data is pack—
`aged. But authors, designers, and publishers are typically not concerned with how data needs to be encoded,
`nor should they be. The industry desperately needs a graphic arts document type (for graphic arts applica
`tions) that is robust enough to withstand the variability of desktop publishing system integration. A PDF
`Digital Master contains much more than all the text, graphics, and images. Fonts and other resources can be
`compactly included because of PDF's compression capabilities. OPI links can also be passed into the docu-
`ment for optimized output of high resolution data. Then there is the information carried by the PJTF data,
`including color management information, imposition and trapping parameters, screening and halftone
`information, press controls (UCR, OCR), and more.
`
`If a PDF file contains the same information as a PostScript file, then how is using PDF different? One reason
`is that PDF offers a new flexibility that PostScript does not have. Although PostScript is a proven technology,
`a PostScript language file is written as an interpreted software program, generally as the output from a graph—
`ics or layout application. The pages in a PostScript file are imaged in order, and as a result, there is no page
`independence. Thus, objects from one page can be dependent on objects from another page. For example, if
`a font is downloaded on an earlier page, a later page that requires that font cannot be printed without the
`earlier page.
`
`In contrast, a PDF file is an object-based file. Each object on a page or resource (like a font) required to image
`that page is independent of other objects and resources used on other pages. Thus, files may be merged.
`documents can be combined, or pages may be deleted without affecting other pages or objects.
`
`With this information, the document can, in effect, correctly configure the computer system that is handling
`it. For example, a PDF file with embedded fonts doesn't depend on having those fonts installed and open on
`the computer. Having a PDF Digital Master will help avoid many of the problems that exist today when
`incorrect computer system configuration produces faulty output.
`
`PETITIONERS EX. 1013, p. 7
`
`PETITIONERS Ex. 1013, p. 7
`
`

`

`PDF's reliability also makes it ideal for remote proofing applications, and because of its visual integrity, this
`Digital Master is ideal for re—purposing content from print to the Internet and back.
`
`There is a misconception in the industry that PDF is not editable. A truer statement might be that the tools
`for extensive editing have not reached the market yet. Once this situation has changed. not only will Ex—
`treme affect the output end of the workflow, but PDF will be poised to claim that it is the first “universal"
`file format for the graphic arts.
`
`What systems can be called Extreme?
`The following six characteristics de