computers St graphics
`
`
`
`Editor-in- Chief‘
`
`José L. Encarnacéo
`ZG DV Computer Graphics Centre,
`Rundesturmstrasse 6, 64283 Darmstadt, Germany
`
`Peter R. Bono
`Vice President,
`Frauhofer CRCG, |nc.,
`321 South Main Street,
`
`A
`
`USA
`
`Clifford A. Pickover
`IBM Thomas J. Watson Research Center,
`Yorktown Heights, NY 10598, USA
`
`Alex Hildebrand
`ZGDV, Computer Graphics Centre,
`Rundesturmstrasse 6,
`D-64283 Darmstadt,
`
`computers RECEIVED
`
`FEB 1 0 I998
`
`LIBRARY SERVICES
`
`Marianne Clemente
`
`an international journal
`of systems S applications
`in computer graphics
`
`algorithms and techniques for interaction,
`[nuIt| [nedi
`'
`'
`'
`'
`a’
`
`_
`_
`_
`Ed|tor-|n.ch|ef
`__
`J. L. Encafnacao
`ZGDV Computer Graphics Centre
`
`In this issue the special topic is
`
`GRAPHICS IN ELECTRONIC PRINTING AND PUBLISHING
`
`Guest Editors: Roger D. Hersch and Jtirgen Schonhut
`
`Associate Editors:
`
`Associate Editor for
`”Chaos & Graphics"Section:
`
`Associate Editors for
`”Education " Section:
`
`Associate Editors for
`"Algorithms Corner" Section:
`
`Lars Kjelldahl
`Numerical Analysis &
`Computing Sciences, NADA,
`Royal Institute of Technology KTH,
`S—10044 Stockholm, Sweden
`
`José Teixeira
`Centro de Computacéo Grafica,
`Rua de Mocambique, 17 R/C ESO,
`3030 Coimbra, Portugal
`
`Michael Gervautz
`Technische Universitat Wien,
`lnstitut fiir Computergraphic,
`Kar|sp|atz13/186/2,
`1040 Wien, Austria
`
`Markus Gross
`lnstitut fur Informationssysteme,
`Department Informatik,
`ETH-Zurich-Zentrum,
`8092 Zurich, Switzerland
`
`Ed,,O,,a,AdV,so,y BM
`Varol Akman
`Ankara, Turkey
`Farhad Arbab
`Amsterdam, Netherlands
`Wilhelm Barth
`Wien, Austria
`R. Daniel Bergeron
`Durham, NH, USA
`Ken Brodlie
`Leeds, England
`Pere Brunet
`Barcelona, Spain
`Daniel Cohen-Or
`Tel-Aviv, Israel
`Dieter Fellner
`Bonn, Germany
`David Duce
`Chilton, Didcot, UK
`Bianca Falcidieno
`Genova, Italy
`James D. Foley
`Atlanta, GA, USA
`
`llio Galligani
`Bologna, Italy
`Robert K. L. Gay
`Singapore
`Bernd Girod
`Erlangen, Germany
`Martin Gébel
`Sankt Augustin, Germany
`Donald P. Greenberg
`Ithaca, NY, USA
`Georges Grinstein
`Lowell, MA, USA
`Richard A. Guedj
`Evry Cédex/Les Epinnetes, France
`Bertram Herzog
`Ann Arbor, MI, USA
`Frederic W. Jansen
`Delft, Netherlands
`Arie Kaufman
`Stony Brook, NY, USA
`Myoung-Hee Kim
`Seoul, Korea
`
`Fumihiko Kimura
`Tokyo. Japan
`Stanislav Klimenko
`Protvino, Russia
`Detlef Kr6mker
`Darmstadt, Germany
`Carl Machover
`White Plains. NY, USA
`Sudhir P. Mudur
`Juhu, Bombay, India
`D. H. Miiller
`Dortmund, Germany
`Eihachiro Nakamae
`Hiroshima, Japan
`Marcio Lobo Netto
`S50 Paulo, Brazil
`Robert D. Parslow
`Hampton, Middlesex, UK
`Bernard Peroche
`St. Etienne, Cédex, France
`Philip K. Robertson
`North Ryde, Australia
`
`David H. Salesin
`Seattle, WA, USA
`Jiaoying Shi
`Hangzhou, China
`Vaclav Skala
`Plzen, Czech Republic
`Seah Hock Soon
`Singapore
`Wolfgang Strasser
`Tubingen, Germany
`Yasuhito Suenaga
`Kanagawa, Japan
`Tetsuo Tomiyama
`Tokyo, Japan
`Bodo Urban
`Rostock, Germany
`Shin Ting Wu
`Campinas, Brazil
`Michael J. Zyda
`Monterey, CA, USA
`
`Author Service Department. For queries relating to the general submission of articles (including electronic text and artwork) and the status of accepted
`manuscripts, please contact the Author Service Depanment: e-mai/.' authors(4_ze|sevier.co.uk; Fax: +44 (0) 1865 843905; Tel: +44 (0) 1865 843900.
`Publishing Office. Elsevier Science Ltd, Bampfylde Street, Exeter EX1 2AH, England [Tel. Exeter +44 (0)1392 251558; Fax +44 (0)1392 425370].
`Annual Institutional Subscription Rates 1 998: Europe, The CIS and Japan, 2051.00 Dutch Guilders; all othercountries, USS1 179.00. Associated Personal Sub-
`scription rates are available on request for those whose institutions are library subscribers. Dutch Gu ilders prices exclude VAT. Non—VAT registered customers in
`the European Community will be charged the appropriate VAT in addition to the price listed. Prices include postage and insurance and are subject to change
`without notice.
`
`Any enquiries relating to subscriptions should be sent to:
`The Americas: Elsevier Science Customer Support Department, PO Box 945, New York, NY 1 001 0, USA [Te/: (+1 ) 21 2 633 3730/1 888 4ES-INFO. Fax: (+1 )
`212 633 3680. e—mail: usinfo-f@elsevler.com].
`Japan: Elsevier Science Customer Support Department, 9-15 Higashi—Azabu 1 —chome, Minato—ku, Tokyo 106, Japan [Te/5 (+81 ) 3 5561 5033. Fax.'(+81) 3
`5561 5047. e-mail.‘ info@e|sevier.co.jp].
`Asia Pacific (excluding Japan): Elsevier Science (Singapore) Pte Ltd, No. 1 Temasek Avenue, 17-01 Millenia Tower, Singapore 039192 [Te/: (+65) 434
`3727. Fax: (+65) 337 2230. e—mai/,'asiainfo@e|sevier.com.sg].
`Rest of the World: Elsevier Science Customer Service Department, PO Box 21 1, 1001 AE Amsterdam, The Netherlands [Te/.' (+31) 20 485 3757. Fax: (+31 )
`20 485 3432. e-mail.' nlinfo—f@elsevier.nl].
`PERIODICALS POSTAGE PAID AT RAHWAY, NJ. Computers & Graphics (ISSN 0097-8493) is published 6 issues per year in February, April, June, August,
`October and December, by Elsevier Science Ltd, The Boulevard, Langford Lane, Kidlington, Oxford OX5 1GB, UK. The annual subscription in the USA is
`$1179.00. Computers & Graphics is distributed by Mercury Airfreight International Ltd, 2323 Randolph Avenue, Avenel, NJ 07001 -2413, USA. POSTMASTER:
`please send address changes to Computers & Graphics, c/o Elsevier Science Regional Sales Office, Customer Support Department, 655 Avenue of the Americas,
`New York, NY 10010, USA.
` m Petitioners‘ Exhibit 1019, pg. 1
`
`
`
`Petitioners' Exhibit 1019, pg. 1
`
`

`
`
`
`Pergamon
`
`Comput. & Graphics, Vol. 21, No. 6, pp. 693—702, 1997
`© 1997 Elsevier Science Ltd. All rights reserved
`Primed in Great Britain
`0097—8493/97 $l7.00+0.00
`
`PII: S0097-8493(97)00047-2
`Graphics in Electronics Printing and Publishing
`
`I-MEDIA: ANINTEGRATED MEDIA SERVER AND MEDIA
`DATABASE AS A BASIC COMPONENT OF A CROSS MEDIA
`
`I
`
`PUBLISHING SYSTEM
`
`JORG ZEDLERT and MARWAN RAMADAN
`
`Fraunhofer-Institut fur Graphische Datenverarbeitung (Fraunhofer Institute for Computer Graphics),
`Rundetrumstrafie 6, 64 283 Darmstadt, Germany
`e-mail: zedler@igd.fhg.de
`
`the so-called Cross Media
`Abstract—The publication of the same information on different media,
`Publishing (CMP), is becoming one of the central aspects in today’s publishing industry. CMP centers on
`a media independent document definition and an efficient integrated publishing on different media: eg. as
`a paper document, as an online document in the World Wide Web, and as an offline (CD-ROM based)
`multimedia presentation. The aim of CMP is to get these different media at the same stage, while—and
`that
`is important—spending an acceptable amount of additional effort
`(in time and money)
`for
`production. In this paper we present a solution for a key problem of Cross Media Publishing,
`the
`handling of media data (images, audio, video, etc.) by using a combined approach of server and database
`systems functionality. The integrated multimedia server and database i-Media and its role in a complete
`CMP solution will be presented. © 1997 Elsevier Science Ltd. All rights reserved
`
`1. INTRODUCTION AND BASIC REFLECTIONS
`
`In these days the publishing industry is alfected by
`enormous changes regarding structures and contents.
`Since the completely electronic production of printed
`documents is becoming more and more common and
`new technologies and media such as the World Wide
`Web (WWW) and CD-ROM based multimedia
`presentations show an overwhelming success,
`the
`traditional workflow in the publishing world is no
`longer timely. Moreover, the publishing world has
`become complex, since several different platforms,
`applications, and media must be supported in an
`open architecture.
`Now that a reader has the possibility to choose
`from different types of media he also expects to get
`the same information irrespective of what he chose.
`He can then decide depending on his situation which
`media platform fits best.
`In this paper we will present a solution for a key
`problem of Cross Media Publishing, the handling of
`media data. A media management system will be
`presented, which offers an added value by a
`combined approach of an object-oriented database
`management system (OODBMS) configured to the
`purposes of an CMP system and expanded with
`additional server functionality, e.g. regarding format
`conversion in an automated, configurable way.
`Conceptually all media types—text,
`image (both
`raster and vector images), audio, video, and anima-
`tion—are supported and the special technical pub-
`
`T Author for correspondence.
`
`693
`
`lishing requirements, e.g. OPI server functionality or
`DTP/multimedia authoring tool support are taken
`into account.
`
`In this section we will shortly explain the require-
`ments of Cross Media Publishing (see Section 1.2).
`We will take a look at the variety of formats and
`standards (Section 1.3) and the media dependent
`advantages, disadvantages and technical restrictions
`(Section 1.4).
`
`l.l. Naming
`The term media is used for a variety of things. To
`avoid confusion, we will use in this paper
`the
`following naming:
`
`0 Images, audio, video, and animations are called
`Media Data or Document Resources or shortly
`Resources. Media data is often saved in special
`media and platform dependent formats.
`0 Documents are published on paper (Print Media)
`or
`as
`electronic documents
`(New Media or
`Electronic Media). Electronic documents could be
`made available either online or oflline. Oflline
`
`documents are usually published on storage media
`such as CD-ROM. Documents are published on
`so—called Target Media or Media Platforms.
`
`1.2. Cross Media Publishing
`In Fig. 1, an example of a cross-media produced
`and published article is shown. It was printed on an
`offset press as a color brochure. Then it was
`converted to an HTML document with embedded
`
`GIF and JPEG images, to a PDF document with
`
`Petitioners‘ Exhibit 1019, pg. 2
`
`Petitioners' Exhibit 1019, pg. 2
`
`

`
`
`
`694
`
`J. Zedler and M. Ramadan
`
`
`
`paper version
`(offset print)
`
`CD-ROM based
`multlmedia presentation
`(Macromedla Director)
`
`HTML based
`WWW presentation
`(Netscape Navigator)
`
`PDF document
`(Netscape Navigator with
`Adobe Acrobat Plug—ln)
`
`Fig. l. CMP example.
`
`integrated “weblinks”, as well as to a CD-ROM
`based multimedia presentation with PICT images
`and additional sound and video clips. A stripped
`version of the multimedia document is also acces-
`sable as a Shockwave document via Internet.
`
`http://www.igd.fhg.de/www/igd-al/crossme-
`See
`dia/index_e.html for the electronic documents.
`The basis of CMP is
`a media independent
`document description. Media independent means
`that you can convert a document (automatically) to
`any media platform.
`K
`To achieve a high quality, the technical require-
`ments of a media independent format are given by
`the media platform with the highest demands.
`Therefore a media independent document contains
`among other things:
`
`0 high resolution raster images (necessary for print,
`although not necessary for screen presentation),
`0 audio, video,
`and animations
`(although not
`supported by print media), and
`0 hypertext functionality (although again not sup-
`ported by print media).
`
`Because of the continuing high acceptance of
`paper documents, Cross Media Publishing is seen
`especially from the print publishing’s point of view.
`Advanced and commonly used publishing systems
`like Adobe FrameMaker, Adobe PageMaker, or
`Quark XPress have to fit into an integrated CMP
`system architecture, as Well as sophisticated author-
`ing tools.
`
`1.3. Formats of the publishing ilzdustry
`In the publishing industry a variety of standar-
`dized as well as proprietary data formats have been
`established. Formats like PostScript, EPS, and TIFF
`for print media or HTML, JPEG, and GIF for the
`Web have to be taken into account when setting up a
`Cross Media Publishing solution.
`In the following we will shortly mention some of
`the most important formats used. A more detailed
`discussion can be found in [1].
`
`1.3.1. Formats of the prepress world. The prepress
`world is coined by the de-facto industry standard
`Adobe PostScript [2] used for document encoding, as
`well
`as
`the derived formats EPS (Encapsulated
`PostScript
`[3]) and AI (Adobe Illustrator), which
`are widely used for interchange of illustrations.
`Raster
`images are usually encoded in TIFF
`(Tagged Image File Format [4]), which can handle
`bitmaps, gray level images, as well as RGB, CMYK
`or even device independently (CIE Lab) encoded
`images in arbitrary resolutions.
`Because of the high resolution of raster images
`there are tremendous requirements due to storage
`capacity in the prepress world. A typical
`letter
`format four color image requires about 30 MByte,
`when encoded as an uncompressed CMYK TIFF.
`To reduce the load on the network and the DTP
`
`computers Aldus has specified OPI (Open Prepress
`Interface [5]), which has become a widely used
`standard. A so-called OPI server manages the high
`resolution images and calculates a low resolution
`sample, which is used for positioning on the DTP
`computer. When sending a document with embedded
`OPI images to a printer, the OPI server substitutes
`transparently for the user the samples by the high
`resolution originals. Using an OPI server can boost
`up productivity during printing easily by a factor of
`100!
`More and more Adobe’s Portable Document
`
`is becoming used as a page
`Format (PDF) [6, 7]
`description language suitable for both displaying on
`screen as well as for printing on b/w or color printing
`devices. Currently PDF is mostly generated by
`“distilling” PostScript (using Adobe’s Acrobat tech-
`nology). Automatic generation of hypertext elements
`(especially links)
`and integration of document
`information in PDF format
`is possible by using
`“pdfmark” commands encoded in PostScript.
`1.3.2. Formats of the World Wide Web (WWW).
`The standard document
`format
`for
`the Web is
`
`HTML [8], which is not a page description language
`such as PostScript or PDF, but a document markup
`language. The layout is not fixed in the document.
`
`
`
`Based upon mar
`appearance of th
`client, depending
`as the adjusted f
`Raster
`image
`Interchange File
`table (LUT) ima
`RGB color imag
`Animations ai
`or Java-Applets.
`ins are widely us
`PDF format by
`clients for free.
`Section 1.4) PD’,
`also.
`1.3.3. Format.
`Multimedia autl
`Director and /
`
`platform specifir
`on Apple Macin
`on Microsoft V‘
`
`example.
`tl
`Moreover,
`formats
`as wr
`
`supported by th
`would be too (:7
`
`1.4. Media plur]
`tee/mica] resmc
`Media platfoi
`either electronic
`offline accessabl
`one media plat
`other platform.
`Advantages:
`
`0 print docume
`readability; ll
`bandwidth p
`(i.e. people :
`layout under
`0 electronic on
`to—date
`infr
`search funct
`tion when yr
`0 electronic (0
`PDF: hypert
`up-to-date i
`good printa‘
`poses; layou
`0 electronic oi
`authoring sy
`presentation
`video, and a
`bandwidth);
`layout uncle:
`
`Disadvantag
`
`0 print docum
`no hyperte:
`‘ animation n
`
`
`
`3
`Petitioners‘ Exhibit 1C)19,
`
`
`Petitioners' Exhibit 1019, pg. 3
`
`

`
`
`
`locument
`Navigator with
`'obat Plug-ln)
`
`id. The prepress
`iustry standard
`ent encoding, as
`(Encapsulated
`Istrator), which
`lustrations.
`oded in TIFF
`1lCh can handle
`
`5 RGB, CMYK
`Lab) encoded
`
`f raster images
`due to storage
`I
`typical
`letter
`)out 30 MByte,
`CMYK TIFF.
`: and the DTP
`
`(Open Prepress
`a widely used
`mages the high
`low resolution
`
`1g on the DTP
`with embedded
`rver substitutes
`
`les by the high
`erver can boost
`
`v by a factor of
`
`,ble Document
`
`ised as a page
`h displaying on
`ar color printing
`generated by
`s Acrobat tech-
`Jertext elements
`of document
`
`isible by using
`)stScript.
`Web ( WWW).
`>r
`the Web is
`
`iption language
`:ument markup
`the document.
`
`i-Media: an integrated media server and database
`
`695
`
`Based upon markups enclosed in the document the
`appearance of the document is defined by the WWW
`client, depending on the current windows size, as well
`as the adjusted fonts.
`‘
`Raster
`images ‘are -encoded in GIF (Graphic
`Interchange File format) for bitmap or color lookup
`table (LUT) images, and JPEG is used for Contone
`RGB color images’
`Animations are supported, e.g. as animated GIF
`or Java—Applets. Extensions via WWW client plug-
`ins are widely used. Adobe is for example pushing its
`PDF format by oiferingplug-ins for several WWW
`clients for free. Because of its good printability (see
`Section 1.4) PDF is becoming common on the Web
`also.
`
`1.3.3. Formats of multimedia authoring software.
`Multimedia authoring systems such as Macromedia
`Director and Asymetrix Toolbook typically uses
`platform specific formats, such as PICT for images
`on Apple Macintosh computers and BMP for images
`011 Microsoft Windows computers, to give just an
`example.
`image
`there are several additional
`Moreover,
`formats
`as well
`as
`audio and video formats
`
`supported by the authoring systems. A complete list
`would be too extensive to be discussed here.
`
`1.4. Media platforms: advantages, disadvantages, and
`rec/znical restr1'cti0ns
`
`Media platforms differ in several aspects: they are
`either electronically available or not, either online or
`oflline accessable, and so on. A typical advantage of
`one media platform is often a disadvantage on the
`other platform. The aspects are listed below in detail.
`Advantages:
`
`0 print document: excellent presentation quality and
`readability; no computer required for reading; no
`bandwidth problems; easy markup; social aspects
`(i.e. people are used to read paper documents);
`layout under control of the publisher,
`0 electronic online document based on HTML: up-
`to-date
`information;
`hypertext
`functionality;
`search functionality; compact format;
`(informa-
`tion when you need it),
`0 electronic (online or oflline) document based on
`PDF: hypertext functionality; search functionality;
`up-to-date information when online accessable;
`good printability; well suited for archiving pur-
`poses; layout under control of publisher,
`0 electronic oflline document based on multimedia
`
`authoring systems, usually on CD-ROM: excellent
`presentation quality on screen; support of audio,
`video, and animation (no problems with network
`bandwidth); hypertext and search functionality;
`layout under control of publisher.
`
`Disadwm rages.’
`
`0 print document: information often not up-to-date,‘
`no hypertext
`functionality; audio, video, and
`animation not supported;
`
`0 electronic online document based on HTML: often
`
`little
`bad presentation quality (publisher has
`control over layout); bad printability; computer
`with network connection necessary; usually small
`network bandwidth; often one logical document is
`divided into several HTML files, which makes
`archiving or printing disadvantageous;
`0 electronic document based on PDF: not well suited
`
`for reading on computer display; computer neces-.
`sary; usually more memory intensive than, e.g.
`HTML-based documents;
`0 electronic CD-ROM based oflline presentations:
`information often not up-to-date; computer neces-
`sary; often bad printability.
`
`Based on the different purposes many different
`formats are used for the encoding of text, images,
`audio, video, and animation. Moreover, the technical
`surrounding conditions are of importance:
`
`0 different color spaces: RGB for displaying on
`screen and CMYK for printing device independent
`color (CIE Lab) not yet Widely used;
`0 different color depth: color tables are famous for
`displaying on screen because of its compactness
`and because of technical limitations of typical PCs
`graphic hardware;
`0 different required resolutions: usually low resolu-
`tion (approximate
`72 dpi)
`for displaying on
`computer
`screens, but
`resolutions of about
`300 dpi (gray and color images) and of up to
`3000 or 4000 dpi (bitmaps) for printing purposes;
`0 different document concepts used in the publishing
`world (page description languages
`(PDL)
`like
`PostScript or PDF as well as document markup
`languages, such as HTML).
`
`for
`restrictions, e.g.
`Following these technical
`every single image used in a document one easily
`gets eight or more different variations in format and
`size! This is one reason why Cross Media Publishing
`nowadays is expensive, because converting images
`(or any other document resource) from one format
`to another is done as a manual step, which is time
`consuming and labour respectively cost intensive as
`well as error prone. Data consistency is in danger
`when no automatic mechanisms are available (ima-
`gine what happens, if an image has to be changed
`when you have eight different variations of this
`image!).
`Here you need a sophisticated media management
`system, which does both the administration of media
`(storage, access control, versioning, data consistency)
`and automated conversions regarding format, size,
`color space or color depth.
`Although multimedia databases are available even
`as products,
`they are ‘lacking support of
`the
`requirements of Cross Media Publishing.
`In the
`following we will propose
`a concept and an
`implementation for an “intelligent” media manage-
`ment system, suitable for CMP purposes.
`
`
`
`Petitioners‘ Exhibit 1019, pg. 4
`
`
`Petitioners' Exhibit 1019, pg. 4
`
`

`
`J. Zedler and M. Ramadan
`696
`2. i-MEDIA: INTEGRATED MEDIA SERVER AND DATABASE
`
`
`
`There are many different application specific
`formats used for these input channels. In the context
`of this paper, application specific files are named as
`Native Format Files. These files are not particularly
`suitable for interchange,
`therefore standard inter-
`change file formats are needed for further processing,
`usually generated by an export module of the above
`mentioned tools and systems. The interchange files
`are called Generic Representation or Source Files. The
`format must be suitable to generate further varia-
`tions needed for
`the different media platforms
`automatically,
`e.g.
`for an image resource EPS
`illustrations or high resolution TIFF images can be
`used.
`
`2.1.2. Integrated “intelligence” of media data. An
`important added value in our approach is
`the
`integrated “intelligence” of media data, which gives
`also the name of the system (i-Media = “intelligent
`media”).
`A media object keeps a log of every conversion
`from one format or size to another (which filter was
`used, which parameters were expected). Therefore, it
`is possible that the user checks in a corrected version
`of an image and the object itself starts to do the
`necessary conversion to all used formats, sizes, color
`spaces, color depths and so on.
`In the example shown in Fig. 2, an image resource
`(iI1nageObject) is illustrated partly. It consists of an
`English and a German (language) variation of an
`image which is created by using Macromedia Free-
`Hand 5
`(FH5). Every version of
`this
`image is
`available as an EPS file (generated by the illustration
`software) and as format variations, which were
`automatically calculated using internal and external
`filters. After calculation the following image files are
`accessible by the CMP system for every version of
`the iImageObject:
`
`0 an EPS image used for print publishing: this serves
`as a generic representation, too (ie. it is used as a
`basis for the calculation of all further variations in
`
`format and size);
`0 a TIFF image used for internal reasons only (it is
`easier to convert
`the raster image format TIFF
`than EPS, which consists of text, raster and vector
`images);
`.
`(a
`0 two BMP images
`thumbnail version for
`previewing and a full screen version for best
`quality displaying) used for Microsoft Windows
`based multimedia presentations;
`0 a small GIF image (again a thumbnail version)
`and a JPEG image for use in a HTML document.
`
`In the example of Fig. 2 the user has checked out
`the English version 1.0e to correct a mistake. After
`correction he checks in a new version (l.le). He puts
`the application specific file (native format file) as well
`as a generic representation of the image (source file,
`in this case the EPS encoded image)
`into the
`database.
`
`Petitioners‘ Exhibit 1019,
`
`5
`
`In this section we will explain the basic concepts
`and functions of the i-Media server and database (see
`Section 2.1) as well as its role in thelcontext of a
`Cross Media Publishing system ‘(see Section 2.2).
`
`2.1. i-Media server and database‘ -
`To handle the different formats mentioned above,
`a multimedia database system is well suited. For the
`special purposes of Cross Media Publishing addi-
`tional support for the user (publisher) is necessary.
`For example conversion of an image from one
`format to another is a task, which could be done
`on an automated way, configured by the special
`needs of the publisher.
`The general idea of i-Media is the integration of
`multimedia database functionality and additional
`functionality like automatic format conversion and
`OPI server functionality. It consists of two parts: the
`database itself and the server, which allows a
`prescribed access to the database.
`The database system part of i-Media handles the
`resources (media data of any kind), especially:
`
`0 native format files (such as Aldus/Macromedia
`FreeHand, Quark XPress or Adobe Photoshop
`files),
`9 links to resources used in the generic files (e.g.
`embedded TIFF or EPS images),
`0 interchange files,
`0 variations of the above mentioned regarding
`
`—versions,
`—formats, and
`—languages used in text.
`
`The server contains:
`
`0 a user and group management which is used to
`grant and restrict access rights to media data (see
`below);
`0 a version management which allows to create new
`version and to remove old versions;
`0 check—in/check-out functionality which allows a
`user to change media data and to lock access
`during changes;
`0 a configurable and extensible set of filters, which
`allow for automatic format conversion as well as
`
`OPI server functionality.
`
`Media data (resources) are stored in an object-
`oriented manner, using an object oriented database
`management system (see Section 3).
`2.1.1. Native format files and generic representa-
`tions. The media data which is stored in the database
`
`come from a variety of input channels. Raster images
`for example are often scanned on drum or flatbed
`scanning devices. Illustrations are usually generated
`by some high level
`illustration software such as
`Aldus/Macromedia FreeHand or Adobe Illustrator,
`video clips are edited by Adobe Premiere or other
`video editing systems.
`
`versi
`
`FH5
`native
`format file
`
`fiiter()
`
`BMP
`
`After checl<—ir
`
`(illustrated with
`matically, witho
`just by traversin
`executing exactly
`What happens
`image resource‘?
`the document hi
`
`were indicated bf
`a newer Version
`Data consistenc
`
`guaranteed by tl
`
`2.2. Integration 1'
`The above-des
`
`system plays a vi
`system. Subseqt
`Media server c
`Cross Media Pu
`
`(see Fig. 3).
`The i-Media s
`
`database 1I12ll’1‘dg
`module and a se
`the i-Media date‘
`external filters (si
`a RIP such as
`
`Scriptworks) can
`
`Petitioners' Exhibit 1019, pg. 5
`
`

`
`i-Media: an integrated media server and database
`
`697
`
`ilmageobject
`
`English
`
`German
`
`version 1.0e ‘
`
`version 1.16
`
`version 1.0g
`
`native
`format file
`
`source file
`finer‘)
`
`
`
`native
`format tile
`
`
`‘ source tile
`l"‘9’()
`
` ii|ter()
`
`.
`mliiiigrtt
`
`ilt r()
`
`1llter()
`
`HE W
`
`mat)
`err
`
`native
`format file
`
`source file
`f”t9'0
`
`fiiter()
`
`filt r()
`
`fl|ler()
`
`Efl @ JPEG
`fitter()
`
`GIF
`
`Fig. 2. An image resource (ilmageObject) checked in after rework.
`
`After check-in of the new version the variations
`
`(illustrated with dashed lines) are calculated auto-
`matically, Without further interaction with the user,
`just by traversing the filter tree of version l.0e and
`executing exactly the same filters for version l.le.
`What happens to the documents that reference this
`image resource? The next time the publisher touches
`the document he can update the references (Which
`were indicated by the CMP system to be old, because
`a newer version of the image resource is available).
`Data consistency on all media platforms can be
`guaranteed by the CMP system.
`
`2.2. Integration into a CMP solution
`The above-described i-Media server and database
`system plays a vital role in a Cross Media Publishing
`system. Subsequently we will explain how the i-
`Media server communicates with its clients,
`the
`Cross Media Publishing system and an OPI server
`(see Fig. 3).
`The i-Media server consists of an object-oriented
`database management system, a user management
`module and a set of internal filters. It has access to
`the i-Media database via an OODBMS. Additional
`
`external filters (stand-alone running applications, e.g.
`a RIP such as Aladdin Ghostscript or Harlequin
`Scriptworks) can be called by the i-Media server.
`
`A Cross Media Publishing system (client A) uses
`the i-Media server for the management of its media
`data. An editor running within the CMP system
`allows the media independent definition of docu-
`ments. Third-party applications such as DTP systems
`allow the creation and modification of media data.
`A set of export modules allow the conversion to
`different media platforms. These “modules” could be
`Converters which allow a fully automated generation
`of media platform specific document (e.g. suitable for
`HTML documents). A module could also be third-
`party stand-alone system such as Quark XPress for
`print publishing or Macromedia Director for multi-
`media presentations.
`‘
`To allow the user of the CMP system to share the
`benefits of the OPI specification, another client of the
`i-Media server, the OPI server (client B) could run,
`e.g. on a powerful workstation and translates OPI
`Postscript (PostScript encoded documents, were OPI
`comments were placed instead of the high resolution
`images) to PostScript, which could be send sent to an
`image or plate setter or even to a digital printing press.
`
`2.3. Advantages
`The advantages of this approach are as follows:
`
`0 the database ensures the consistency of the data,
`even if last minute changes have to be made and
`
`Petitioners‘ Exhibit 1019, pg. 6
`
`ulication specific
`Is. In the context
`les are named as
`
`not particularly
`standard inter-
`
`rther processing,
`lule of the above
`
`interchange files
`Source Files. The
`te further varia-
`
`nedia platforms
`5
`resource EPS
`
`F images can be
`
`"media data. An
`
`the
`tpproach is
`lata, which gives
`ia = “intelligent
`
`zvery conversion
`(Which filter was
`ad). Therefore, it
`zorrected version
`starts to do the
`
`nats, sizes, color
`
`n image resource
`It consists of an
`variation of an
`acromedia Free-
`
`image is
`this
`’
`y the illustration
`us, which were
`nal and external
`
`lg image files are
`every version of
`
`shing: this serves
`.e. it is used as a
`her variations in
`
`:asons only (it is
`ge format TIFF
`taster and vector
`
`ail version for
`Version for best
`rosoft Windows
`
`tmbnail version)
`TML document.
`
`has checked out
`a mistake. After
`
`n (l.le). He puts
`rmat file) as well
`iage (source file,
`mage)
`into the
`
`Petitioners' Exhibit 1019, pg. 6
`
`

`
`
`
`In the iMedi
`all media data 1:
`the native forma
`files, the variant
`user information
`An overview c
`
`given in the fOll(
`
`Attribute:
`
`Name:
`
`Version:
`
`Format:
`
`Language:
`
`Backtracking:
`Owner:
`
`Checked:
`
`subclasse
`All
`iMediaClass. Tl
`
`media dependen
`especially of a l
`
`|_____
`
`the resource cla
`not make sense
`
`audio compress
`
`3.2. Usage offil
`3.2.1. Canoe}
`done by a gro
`example there
`i
`media format
`with country s
`lauts), filters to
`tion or quanti
`(24 bit) to 4 bi
`name just a fevs
`
`
`
`User
`Management
`
`OODBMS
`
`
`
`i-Media
`
`Database
`
`
`
`lntemai Filters
`
`External Filters
`
`Fig. 3. Architecture of i-Media server and database and its clients (CMP system and OPI server).
`
`several variations in format, color space, color
`depth and size of an image are in use
`0 the i-Media server relieves the user of manual and
`recurrent tasks like format conversion
`
`the publisher can
`0 and as a result of the above:
`publish his document on several media while
`spending an acceptable amount of additional
`effort.
`
`3. INIPLEMENTATION
`
`In this section we will explain some implementa-
`tion details of the i~Media system. It has to be stated
`that the system is currently under development and
`still much has to be done.
`
`Because of the complexity of the i-Media system it
`is neither eflicient nor affordable to implement
`it
`from scratch. Moreover, several of the problems we
`have to solve, especially regarding database func-
`tionality, are already implemented in a variety of
`systems which can be used as implementation basis.
`
`3.1. Media class /zierarc/zy
`We have identified five different classes of docu-
`
`ment resources: text, images (both raster and vector
`images), audio, video, and animation.
`the
`Although several aspects are specific for
`different classes (e.g. which formats were used for
`encoding and which filters are available for conver-
`sion), there is media object information, which has to
`be supported independent of the class.
`As a result the document resources are organized
`a hierarchy of classes, with a virtual class
`as
`(iMediaClass) as the root class; see Fig. 4. The
`derived classes are:
`
`iTextClass for text,
`ilmageclass for raster and vector images,
`iAudioClass for sound and other audio data,
`ivideoclass for videos,
`iAnimat ionC lass for animations (e.g.
`mated GIF or Java applets).
`
`ani~
`
`
`
`iMediaCiass
`
`
`
`
`
`iAnimationClass
`
`iVideoClass
`
`
`
`iAudioClass
`
`
`iTextC|ass
`
`iimageciass
`
`Fig. 4. iMediaClass hierarchy.
`
`
`
`Pet