OPI White Paper
`OPI White Paper
`
`PETITIONERS Ex. 1008, p. 1
`
`PETITIONERS Ex. 1008, p. 1
`
`

`

`K Apple Computer, Inc.
`All rights reserved. Under the copyright laws, this document may not be copied, in whole or in part, without the
`written consent of Apple.
`The Apple logo is a registered trademark of Apple Computer, Inc. Use of the “keyboard” Apple logo (Option-
`Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark
`infringement and unfair competition in violation of federal and state laws.
`Every effort has been made to ensure that the information in this manual is accurate. Apple is not responsible
`for printing or clerical errors.
`© 1995 Apple Computer, Inc.,
`1 Infinite Loop
`Cupertino, CA 95014-6299
`(408) 996-1010
`Apple, the Apple logo, AppleShare, AppleTalk, LaserWriter, Macintosh, and QuickTime, are trademarks of Apple
`Computer, Inc., registered in the United States and other countries. AppleScript, Mac, and PhotoFlash are
`trademarks of Apple Computer, Inc.
`Adobe, Adobe Illustrator, Adobe Photoshop, Fetch, OPI, PageMaker, PostScript, PressWise, and TrapWise are
`trademarks of Adobe Systems, Incorporated, which may be registered in certain jurisdictions.
`AGFA is a trademark of Agfa Geveart.
`AIX and IBM are registered trademarks of International Business Machines Corporation.
`Kodak is a trademark of Eastman Kodak Company.
`Microsoft, MS-DOS, Microsoft Windows, and Windows NT are registered trademarks of Microsoft Corp.
`NetWare and Novell are registered trademarks of Novell, Inc.
`NextStep is a trademark of NeXT, Inc.
`PowerPC is a trademark of International Business Machines Corporation, used under license therefrom.
`Quark and QuarkXPress are registered trademarks of Quark, Inc.
`QuickMail is a trademark of CE Software, Inc.
`Sony is a registered trademark of Sony Corporation.
`SPARC and Sun are trademarks of Sun Microsystems, Inc.
`UNIX is a registered trademark of UNIX Systems Laboratories, a wholly-owned subsidiary of Novell, Inc.
`
`Other brand or product names mentioned in this document may be trademarks or registered trademarks of
`their respective companies.
`Mention of third-party products is for informational purposes only and constitutes neither an endorsement nor
`a recommendation. Apple assumes no responsibility with regard to the selection, performance, or use of these
`products. All understandings, agreements, or warranties, if any, take place directly between the vendors and the
`prospective users.
`
`PETITIONERS Ex. 1008, p. 2
`
`

`

`Contents
`
`Executive Summary
`
`5
`
`Content review........................................................................................................................6
`
`OPI: The first step toward client/server prepress
`
`7
`
`OPI servers ..............................................................................................................................7
`What happens when you click Print......................................................................................8
`OPI function 1: Print serving..................................................................................................8
`OPI function 2: Image swapping .........................................................................................10
`Extending OPI with additional services...............................................................................13
`Extending OPI with database production management....................................................13
`Extending OPI with client/server image manipulation ......................................................14
`Summary ...............................................................................................................................14
`
`The Supply Side of the OPI Market: OPI developers and vendors
`
`15
`
`The basic facts.......................................................................................................................15
`Why the Mac OS platform dominates in OPI environments .............................................16
`Product profiles ....................................................................................................................17
`Other OPI products..............................................................................................................25
`
`The Demand Side of the OPI Market: Market size, composition, and user profiles
`
`27
`
`The ROI of OPI......................................................................................................................27
`The market size.....................................................................................................................28
`OPI market potential 1995–2000.........................................................................................29
`User profiles..........................................................................................................................30
`Summary and conclusion.....................................................................................................37
`
`Glossary
`
`39
`
`3
`
`PETITIONERS Ex. 1008, p. 3
`
`

`

`PETITIONERS Ex. 1008, p. 4
`
`PETITIONERS Ex. 1008, p. 4
`
`

`

`Executive Summary
`
`This document covers a category of applications known in the printing and publishing
`industries as “OPI servers.” With an estimated installed base of about 10,000 sites, this is a
`distinct and important category of productivity solutions for publishing.
`The installed base of OPI servers to date just scratches the surface of the total market
`potential. Estimates developed for this document indicate that the incremental market
`opportunity for 1995 is about 20,000 sites worldwide. Over the next five years, as more of
`the worldwide publishing industry moves away from proprietary systems and OPI products
`decrease their prices and increase their feature set, the total number of installations is
`expected to expand to more than 200,000 sites worldwide. In hardware alone, the OPI
`market represents an opportunity of close to a billion dollars.
`“OPI” literally means Open Prepress Interface, a name given to a specification
`developed in 1989 by Aldus Corporation. The goal of the specification was to establish a
`structure for linking existing high-end color systems to desktop publishing systems.
`Today, OPI has assumed a much broader role than the narrow focus of the original
`Aldus specification. OPI now refers to a general image-swapping procedure for page layout.
`Low-resolution image files—called “proxies,” “previews,” or “FPOs”—are used for page
`design. Subsequently, at print time, the low-resolution images are replaced by corresponding
`high-resolution files needed to obtain quality reproduction on press.
`Image swapping then opened the door to what has become a second important
`function of OPI—managing high-resolution output with print services. Print services
`physically separate layout from output: the output can be in a different room, a different
`department, or miles away. It also enables layout and output be to scheduled independently.
`The two components—print services and image swapping—are bound tightly in the
`informal understanding of the term OPI. An “OPI server” has become synonymous with a
`client/server solution that offers this mix of functionality. Virtually all of these OPI products
`target Macintosh clients. The most successful, Color Central from Adobe™ Systems, is
`identified primarily with a Mac OS server application. However, Color Central is available
`for Windows NT servers and their competitors support Macintosh clients from UNIX®
`and NetWare servers as well. The Mac OS applications have succeeded on the basis of
`ease-of-use and total system economics, but are challenged by what the industry views as
`“industrial strength” server technology.
`
`5
`
`PETITIONERS Ex. 1008, p. 5
`
`

`

`Recently, a variety of additional services have been added to the OPI framework,
`including links to ISDN, relational databases, and server-based image manipulation systems.
`It is clear that OPI provides the foundation for a family of client/server prepress applications
`that serve the printing and publishing industry as a way to automate production, and
`transform what traditionally has been an artisan activity into a manufacturing activity.
`
`Content review
`This document provides a comprehensive overview of OPI.
`• Chapter 2 covers the basic OPI functions in detail. An explanation of how it works and
`why it works is provided along with details about the future development directions for
`OPI products.
`• Chapter 3 addresses the supply side of the OPI market. Profiles of the major developers
`and their products are provided.
`• Chapter 4 addresses the demand side of the OPI market. The chapter begins with an
`overview of the market demand for OPI products reported for each major market segment.
`Concluding the chapter is a series of OPI user profiles.
`
`This document concludes with a glossary of terms that are relevant to the discussion
`of OPI.
`
`6
`
`OPI White Paper
`
`PETITIONERS Ex. 1008, p. 6
`
`

`

`OPI
`The first step toward client/server prepress
`
`A story is told how Mr. Morita of Sony hosted a mid-1960’s gathering of industry mavens
`to sneak preview the Walkman technology. First he explained the concept, a small portable
`radio/tape player with great stereo sound. Then he ushered the group into an R&D lab
`where they saw a device with hundreds of wires occupying most of a work bench. One
`reporter asked the obvious, how could Sony expect a person to carry around so much
`stuff? According to the story, Morita replied, “First we make it work, then we make it small.”
`Similarly, as we look back on almost a decade of desktop publishing innovation—on
`the giant steps represented by PostScript™, PageMaker, XPress, Illustrator, Freehand, and
`Photoshop—the experience can be viewed as the prototyping stage. The industry made
`it work; now it has to make it work well, by adding the pieces of technology that
`concatenate and coordinate the applications and keep track of the work.
`Taken together, this new class of technology will transform the prepress activity from
`an artisan model to a group activity oriented around and organized by server hardware
`and client/server software. Accordingly, the new model is called client/server prepress.
`The model applies equally well to newspapers, magazines, ad agencies, service bureaus,
`or any setting where people work as a group to design and/or output publications.
`Eventually, these server-based applications may become as sophisticated as the software
`used to manage manufacturing, where the groupware itself provides the principle for
`organizing the workflow. In the first few generations of development, however, client/server
`applications for publishing have focused on solving big obvious problems.
`
`OPI servers
`To date, the most successful and widespread application in the client/server category is
`what the industry calls an OPI server. Understanding this application type is mandatory,
`both to be an informed participant in the industry, and also to develop a sense of the
`trajectory of the entire client/server technology set. Yet one encounters rampant fuzziness
`and misconception, due perhaps in part to the name alone. “OPI” — Open Prepress
`Interface—communicates almost nothing about the nature of the application. Therefore,
`a full review of the OPI foundations is germane to understandingthe client/server picture.
`
`7
`
`PETITIONERS Ex. 1008, p. 7
`
`

`

`Figure 2a Three-step structure for printing;
`particular case of QuarkXPress and
`software RIP
`Input: (cid:13)
`XPress data structure
`
`STEP 1(cid:13)
`Translation to (cid:13)
`PostScript
`
`Output: PostScript
`
`Input:(cid:13)
`PostScript
`
`STEP 2(cid:13)
`Translation to (cid:13)
`bit map
`
`Output: Bit map
`
`Input:(cid:13)
`Bit map
`STEP 3(cid:13)
`Translation to (cid:13)
`image
`
`Output: Image
`
`The name aside, what an OPI package does is provide two kinds of functionality: print
`spooling and image swapping. The first function liberates the printing workstation from
`direct interface to the marking device. The second function insures that the file sizes
`transmitted by the printing workstation are small and manageable. Both of these topics
`are covered at length in the sections that follow, but first we take a small detour to review
`the printing process on the desktop.
`
`What happens when you click Print
`The reason that there is a place for OPI at all is that, when printing, the workstation and
`the marking device are only loosely bound together. Here is what happens when you
`click Print:
`
`Step 1
`The data structure is translated into some common graphics language, PostScript being
`the high-end graphics language standard.
`This translation is done on the workstation, and for high-end publishing programs, the
`translation is done by the layout application itself. When you click Print in XPress, for example,
`it is XPress itself that converts the layout from XPress internal format to PostScript.
`
`Step 2
`The graphics language data is translated into a bit map, if monochrome, or four bit maps
`(CYM&K), if color.
`This translation is done by an application called a raster image processor, or RIP. The RIP
`may be resident in the ROM of the dedicated computer inside of the marking device—
`resident in the ROM of a printer controller board in a LaserWriter, for example—in which
`case it is called a “hardware RIP.” On the other hand, the RIP may be resident on a standard
`computer on the network, in which case it is called a “software RIP.”
`
`Step 3
`The bit maps are communicated to the imager, which deposits pigment on paper, if a
`printer, or exposes film, if an imagesetter.
`An important note here is that in the case of a software RIP, this communication is managed
`by a printer driver, yet another application resident on the same computer as the RIP.
`
`Figure 2a reviews this process schematically for one of the most common combinations
`in high-end publishing.
`
`OPI function 1: Print serving
`The very first client/server functionality in desktop prepress was print serving. Print
`servers were a response to two significant problems. First, big files take a long time to RIP
`and image, and with ordinary imaging, the user is locked out of any other work while
`waiting for the print job to finish. Second, if additional users want to print while a first is
`printing, they all wait.
`
`8
`
`OPI White Paper
`
`PETITIONERS Ex. 1008, p. 8
`
`

`

`Figure 2b The printing process with added
`print server
`Workstation(cid:13)
`Translates to PostScript and (cid:13)
`dispatches file to print server
`
`Print server (cid:13)
`Queues the PostScript files(cid:13)
`and dispatches them to RIPs (cid:13)
`in printers or imagesetters
`
`Printer or imagesetter(cid:13)
`n RIP converts PostScript files (cid:13)
` to bit map and dispatches (cid:13)
` them to imager(cid:13)
`n Imager transfers bit map to (cid:13)
` paper or film(cid:13)(cid:13)
`
`What the print server does is to intervene at the end of step 1 in the printing cycle.
`Using the Figure 2a situation as an example, the layout station is disconnected from the
`RIP and connected instead to the print server. When the user on the layout station clicks
`Print, XPress generates a PostScript file that is sent to the print server. The print server
`queues the PostScript files and outputs them in order to the RIP. In this fashion, a three-
`step process is converted to a four-step process, but the new step is one that offers
`pooling possibilities. Because of the additional step, the first person to print does not
`have to wait for the job to be imaged to recover use of the workstation, the second does
`not have to wait for the first to finish before beginning to transmit, the third does not
`have to wait for the second, and so on.
`This means the print server offers a productivity gain because people do not have to
`wait to recover the use of their computers. They communicate indirectly with the imager,
`through the intermediation of the print server. The print server cannot make the imaging
`faster, but it does gather and dispatch the imaging jobs.
`Figure 2b shows the print server in the middle of the client/server printing sequence.
`As long as it performs its primary function, a number of secondary functions can be added.
`None of these are important enough to generate demand for the product; only the relief
`from waiting on print dialog boxes can do that. However, these other functions
`incrementally improve the efficiency of the group prepress activity. Typically, they include:
`• Providing queues for and connections to several imagers at once
`• Providing different resolution queues to the same imager
`• Providing different paper type queues to the same imager
`• Providing queue management—access privileges, queue priorities, reports, special handling
`
`The different product offerings for print servers all provide a basic service and
`compete on the scope and functionality of these additional services. For example, the
`marketing literature for one product will claim it can manage a large number of printers,
`and the literature for a second might emphasize the reliability and speed in managing a
`group of print queues. A UNIX or Windows NT product will excel in the areas where
`multitasking facilitates simultaneous attention to the users at their workstations and to
`the imagers on the network. A Mac OS product will excel in the ease of installation and
`setup with the additional advantage of creating a customized workflow with AppleScript.
`As with any program, the basic features fulfill 90% of the need, and the more exotic
`features are rarely used. For example, the full power of multitasking is rarely necessary,
`and the extra cost of a UNIX server is rarely reflected in extra value or productivity.
`In the Mac OS environment, it would have been rather easy for Apple to supply a
`more robust print server as a companion to AppleShare. But they did not, opening the
`door to what was then a small company, Compumation, to dominate this product niche
`with its application Print Central, which sold several thousand copies before Compumation
`was acquired by Aldus, which was subsequently acquired by Adobe. Now an Adobe
`product, Print Central continues to be market-share leader in the Mac OS market for
`print server applications.
`
`OPI: The first step toward client/server prepress
`
`9
`
`PETITIONERS Ex. 1008, p. 9
`
`

`

`Table 2a Determining image file sizes
`
`The size of a picture file, in bytes, is determined
`this way. First, determine the bytes in one color
`plane, with the formula: bytes in one color plane
`= pixel count across the top x pixel count along
`the side. Second, determine the bytes in all of the
`color planes: multiply by one for monochrome, 3 for
`RGB, and 4 for CYMK.
`Example:
`
`A monochrome image 5 pixels
`wide by 5 pixels high has 25
`pixels in total. Because it is
`monochrome, each pixel is
`represented by a single number
`representing one out of a possible
`256 grey levels. 256 is the number
`of levels that can be represented
`by eight bits, or one byte, of digital
`information. Hence, 5 pixels wide
`by 5 high is 25 bytes.
`
`Different perspectives on this size relationship are
`available. For example, the pixel count across the
`top of a picture plane is the width times the
`resolution that has been set manually in the
`scanning or image preparation stages, the basis
`for which is the relationship, set resolution =
`lines per inch in screening x quality factor. The
`quality factor between 1.5 and 2 is usually
`selected. The rule-of-thumb is, use 2. Therefore,
`in U.S. magazines that print at 133 lines per inch
`photo screening, the size of a one inch by one
`inch color photo (4 color planes) is given by total
`size for one square inch on paper = 4 x (133 x 2)
`x (133 x 2) = 283,024 bytes, or 283K.
`
`OPI function 2: Image swapping
`Although the print serving function may be the most commonly accessed service of an
`OPI server, it is the image swapping function that attracts the most attention in product
`reviews and marketing literature. In brief, image swapping enables a page designer to
`work with a small screen-resolution picture file during page design and then rely on the
`intervention of the OPI server to swap it out for the high-resolution, color-separated file
`necessary to render the picture in print. The full details of this process are the focus of
`this section.
`Picture files get large fast; it comes with the territory. In a typical U.S. magazine, for
`example, a file for printing a one inch by one inch color picture would be 283K. A two-
`inch by two-inch color picture would be 1.1 MB. The cover of Esquire magazine is 25 MB.
`It gets worse. Many Asian and European magazines use higher line screens (150 vs. 133,
`or even 175 vs. 133 lines per inch). IdN magazine in Hong Kong routinely publishes the
`complete file sizes for all their contents. The IdN cover is 42 MB. A recent 4-page piece
`comparing flat bed scanner output was 215 MB. Table 2a provides a formula for
`determining image file sizes.
`It comes as no surprise that these kinds of file sizes can cause big problems at print
`time. Simply transmitting a 215 MB file in real Ethernet conditions is a 20- to 30-minute
`exercise, during which time the sending and receiving computers are virtually
`immobilized and the network is compromised. In a production environment such as a
`service bureau or a print shop, repetitive transmission of big files (from the scanner to the
`design station, from the design station to the imagesetter) can cause major efficiency
`losses throughout the day. In a newspaper, where most of the imagesetting is
`concentrated in a small time window before going to press, this problem can make the
`whole desktop model unworkable.
`The solution to these problems is image swapping, managed by the OPI server.
`Here’s how it works: First, the page layout is done with a preview image instead of the
`high-resolution image. Due to color component reduction, resolution reduction, and
`compression, the preview file is dramatically reduced in size compared to the original
`file. In the example in Table 2b, the preview sizes are 1% to 3% of the full resolution size,
`depending on the type of publication.
`
`Table 2b Comparison of high resolution and preview file sizes, showing components of total
`reduction for an 8-inch by 10-inch final printed size file (all figures in Megabytes)
`
`Total reduction
`Screen res vs. Compressed vs.
`RGB
`High-res Preview (high-res less
`file size file size preview file size) vs. CYMK printing res
`uncompressed
`
`Three sources of file reduction
`
`Newspaper
`Magazine
`Book
`
`9.2
`22.6
`39.2
`
`0.2
`0.2
`0.2
`
`9.0
`22.4
`39.0
`
`2.3
`5.7
`9.8
`
`2
`12
`24.5
`
`4.7
`4.7
`4.7
`
`10
`
`OPI White Paper
`
`PETITIONERS Ex. 1008, p. 10
`
`

`

`Figure 2c PostScript illustration in a page-
`layout program
`
`EPS Illustration File
`
`Resource Fork(cid:13)
`
`Data Fork(cid:13)
`
`PICT Preview(cid:13)
`(bit map)
`
`PostScript(cid:13)
`code
`
`Layout (cid:13)
`Program
`
`To import graphics(cid:13)
`Layout program opens up (cid:13)
`PICT preview and designer (cid:13)
`places it in layout.
`
`To print layout(cid:13)
`Layout program accesses (cid:13)
`illustration file’s PostScript (cid:13)
`code and sends it to RIP (cid:13)
`along with the layout (cid:13)
`information.
`
`Second, the form of the sample file has a special structure that meshes appropriately
`with the layout program. The genesis of this form, and perhaps the genesis of the entire
`OPI swapping routine, was serendipitous. It is based on a solution that was developed
`originally to enable designers to visualize the PostScript illustrations they placed in
`XPress or PageMaker layouts. Since XPress and PageMaker cannot render PostScript to
`the screen, a special system was developed, which works like this:
`• Illustration programs include the option of saving a PICT preview in the resource fork of
`the file; the corresponding PostScript information is in the data fork of the illustration.
`The PICT preview is a 72 dpi rendering of the PostScript data, which may be compressed
`using QuickTime (JPEG) compression.
`• When the Illustrator file, for example, is “placed” in the layout, the PICT preview is
`opened by the layout program and the user positions and crops it.
`• At print time, when the layout program converts from its own data structure to the
`PostScript data structure, the preview from the resource fork is deleted and replaced by
`the content of the data fork—PostScript code that defines the illustration. Finally, the
`illustration is rendered at full resolution in the RIP. This procedure is shown in Figure 2c.
`
`A major innovation was made by Tim Gill at Quark in 1988. He was seeking a procedure to
`handle data that XPress users would receive from high-end scanners. This data was
`already separated into components for each of the process colors—cyan, yellow, magenta,
`and black. Tim’s innovation was the Encapsulated PostScript–Desktop Color Separation
`(EPS-DCS) format.
`A picture saved in EPS-DCS format consists of five files. Four of the files are EPS files
`with data for each of the separations. The fifth file is like an illustration in that it has a low-
`resolution preview saved as PICT in the resource fork. When a designer selects the fifth
`file from the “Get Picture . . .” dialog in XPress, the PICT is opened into the picture box
`and used for cropping, rotating, and scaling. At print time, instead of substituting
`PostScript code, as in the illustration case, XPress substitutes the appropriate high-
`resolution file into the print stream.
`This procedure gave rise to a workflow system that is still used widely as an alternative
`to OPI servers. The EPS-DCS files are saved on a server. At the layout station, the EPS-DCS
`preview is opened and placed. When the document is complete, it is saved to the server
`in a folder with all of the full separation files. Finally, the layout program is opened on the
`server and prints the layout from the server.
`This is a system that works well in an environment that can follow meticulous file
`management protocols and can control the file formats precisely. It breaks down at the
`slightest glitch in workflow management and where there is no control over the incoming
`picture file formats.
`The final step in the evolution of OPI image swapping came when an unknown
`computer engineer realized that the XPress DCS image swapping system provided the
`structure for other kinds of image swapping. The preview file did not have to be a DCS
`file, it could be any EPS file with a PICT preview at the right address in the resource fork.
`One could put a PostScript message in the data fork, and XPress would interpret that as
`PostScript code and include it in the print file. One need only intercept the print file
`prior to delivery to the RIP, and replace the message with a PostScript bit map call that
`would trigger the RIP to use the correct high-resolution file.
`
`OPI: The first step toward client/server prepress
`
`11
`
`PETITIONERS Ex. 1008, p. 11
`
`

`

`What should be the right software to carry out the procedure, to intercept this message
`and replace it with the right call? The print server, of course, which was already managing
`the delivery of the PostScript layout file to the RIP. Thus was born the modern OPI server,
`in function, if not in name. Schematically, the full OPI swapping procedure is shown in
`Figure 2d.
`Where did the name come from? Ironically, it came from Aldus, whose PageMaker
`encountered the same difficulties as XPress. At about the same time that Quark was
`inventing the EPS-DCS file format, Aldus was independently developing an image
`swapping procedure based on TIFF files, and published a specification for the model
`using the name “Open Prepress Interface.” Whereas the EPS approach built on the
`structure inherent in the illustration solution, the Aldus specification required special
`support that was incorporated subsequently into both PageMaker and XPress.
`Today, one finds a mixture of the two approaches. The leading OPI server products
`use the EPS approach, and most vendors offer EPS as at least one of the options. Several
`vendors support the TIFF specification. The name OPI is applied to both. Most users have
`found that the EPS approach is the most efficient, both for previews and separated files.
`There are two more parts of the technology set that complete the image swapping
`function. First, there has to be some way to generate the preview file, and each of the
`OPI vendors focus on this element as an area of intense competition. Brand A claims its
`preview module is X times faster than Brand B’s. Brand B claims its preview module is
`better because it can handle a wider variety of original file formats than Brand A.
`Typically, the functionality is similar in each solution: The user saves a CYMK file to a
`particular folder. That triggers a routine that creates a preview file and puts it in a different
`folder. One of the virtues of this procedure is that it supports a division of labor in the
`group prepress activity. The scanner department only needs to know about the folder
`where it leaves the completed scans. The layout department only needs to know about
`the folder where it finds the previews. This division of labor has given rise to a way of
`working in many catalog and magazine situations in which the scanning and output is
`done at a service bureau, and the preview files are accessed via modem by editorial staff
`who never see the high-resolution data.
`The final part of the swapping technology is the mechanism by which the server
`software finds the high-resolution files at print time. One solution is an ordered search
`through folders on and off the server. The other solution is to keep track of everything
`with a special database.
`In the desktop applications set, the image swapping functionality has a special elegance
`due to its simplicity and impact. It makes everything work better—the layout team, the
`scanning team, the network performance, and the printing performance. It opens the
`door to geographical separation in prepress and organizational innovation. By binding it
`closely to the print server in the creation of the OPI server, the developers have created a
`product that has immediate payback and widespread appeal.
`
`Figure 2d OPI image-swapping process
`
`Workstation. . .(cid:13)
`. . . creates layout page (cid:13)
`with preview image...
`
`300K preview
`
`. . . then creates (cid:13)
`a PostScript file (cid:13)
`replacing preview (cid:13)
`with OPI comments
`
`2K preview
`
`Print server (cid:13)
`n Uses OPI comments to(cid:13)
`
` locate high-resolution file(cid:13)
`n Replaces OPI comments with color-separated, (cid:13)
` high-resolution files before dispatching to printer
` or imagesetter
`
`magenta(cid:13)
`plate(cid:13)
`(1500K)
`
`cyan(cid:13)
`plate(cid:13)
`(1500K)
`
`black(cid:13)
`plate(cid:13)
`(1500K)
`
`(cid:13)y
`
`ellow(cid:13)
`plate(cid:13)
`(1500K)
`
`12
`
`OPI White Paper
`
`PETITIONERS Ex. 1008, p. 12
`
`

`

`Extending OPI with additional services
`Another virtue of OPI servers is that they have proven to be the kernel of an ever-widening
`circle of client/server functionality. The first category of services is additional procedures
`for the print files. Just as the OPI server can swap image files before it passes the PostScript
`file off to the RIP, it can also carry out additional manipulations of the PostScript files,
`both before and after they are printed. Here are three examples:
`• Trap the file
`The OPI server can call in a trapping program, such as Trapper from Island Graphics or
`TrapWise from Adobe, to adjust the PostScript graphics to improve printing output.
`• Impose the file
`The server can impose the pages in a file using an application like Impostrip from
`Ultimate Technologies or PressWise from Adobe. In this service, a series of pages are
`reordered, reoriented, and then laid out automatically into a meta-page that is output on
`a single piece of imagesetter film. Without digital imposition, this step has to be done
`manually by the printer in order to create the multi-page plates used in printing
`signatures.
`• Archive the file
`Once printed, the server can dispatch a file to an archive, passing along all relevant
`statistics about the printing process (date, time, place, fonts, pictures, illustrations, and
`so on).
`
`Adobe and Agfa have recently developed a novel structure for these and other service
`options in their applications called OPEN and Mainstream, respectively. These applications
`let the user construct virtual production lines. For example: trap, then swap, then print,
`then archive; or swap, then impose, then print.
`With OPEN, each of these production lines is given a name which subsequently appears
`in the Chooser. This way, the Chooser mechanism, which was originally designed for
`selecting printers, then extended to selecting print queues, has been further extended to
`selecting multifunction queues. The user “prints” to whatever virtual production line i