HELSINKI UNIVERSITY OF TECHNOLOGY

Department of Automation and Systems Technology

Timo Laitinen

PRINT SUPPORT FOR MHP

Master’s thesis for the degree of Master of Science in Technology submitted for inspection, Espoo, 19.4.2005.

Supervisor Professor Pirkko Oittinen

Instructor Tuomas Venho, M.Sc.

HELSINKI UNIVERSITY OF TECHNOLOGY

ABSTRACT OF MASTER’S THESIS

Author, topic

Timo Laitinen Print Support for MHP

Date: 19.4.2005 Number of Pages: 67

Department

Department of Automation and Systems Technology

Professorship

AS-75 Media Technology

Supervisor

Professor Pirkko Oittinen Instructor

M.Sc. Tuomas Venho

Printing is one of the fundamental services available in desktop computer environments. It can be assumed that also the interactive digital television could benefit from the possibility to access printing services. However, the software environment supported by digital television receivers, defined by the Multimedia Home Platform (MHP) standard, does not currently provide print support for the interactive television applications. This study focused on finding a printing solution applicable to MHP environment. Two different approaches were identified. A solution built on top of a standard MHP environment could be implemented with the help of an external print server, which would handle most of the aspects related to printing. Another approach is based on platform extensions; the print support could be implemented as a service by the platform. The platform-level print support was seen as a long-term solution and was studied further. An analysis of existing Java printing tools revealed that the print support would be best implemented with the Java Print Service (JPS) API which is part of the standard Java platform. The API would provide an advanced printing interface for the television applications. The conclusion was that the print support would be best achieved by extending the MHP environment with the JPS API. The implementation and use of JPS in MHP environment was analyzed and the solution was simulated with a test system. Although the JPS extension was considered a good candidate to be included in a future MHP standard, details relating to the standardization of the solution were not covered.

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Opiskelija, aihe

Timo Laitinen Print Support for MHP

Päiväys: 19.4.2005 Sivumäärä: 67

Osasto

Automaatio- ja systeemitekniikan osasto

Professuuri

AS-75 Viestintätekniikka

Valvoja

Professori Pirkko Oittinen Ohjaaja

DI Tuomas Venho

Tulostaminen on yksi tietokoneiden peruspalveluista. Voidaan olettaa, että myös digitaalisen television tarjoamat interaktiiviset palvelut voivat hyödyntää tulostusmahdollisuutta. Digisovittimien tukema ohjelmistoympäristö, jonka määrittelee Multimedia Home Platform (MHP) standardi, ei kuitenkaan tällä hetkellä tarjoa tulostustukea. Tässä tutkimuksessa keskityttiin MHP-ympäristöön soveltuvan tulostusratkaisun määrittelyyn. Kaksi lähestymistapaa tunnistettiin. Standardinmukaiseen MHP-ympäristöön perustuva ratkaisu pystytään toteuttamaan, mikäli järjestelmän apuna käytetään erillistä tulostuspalvelinta, joka hoitaisi suurimman osan tulostusprosessista. Toinen lähestymistapa perustui MHP-ympäristön laajentamiseen; tulostuki toteutettaisiin alustan tarjoamana palveluna. Jälkimmäinen, alustatason tulostustuki nähtiin kestävämpänä ratkaisuna ja se valittiin ratkaisun pohjaksi. Olemassaolevien Java-pohjaisten tulostustyökalujen vertailu paljasti, että tulostustuki voitaisiin toteuttaa Java Print Service (JPS) rajapinnan avulla. JPS on kehittynyt tulostusrajapinta ja osa nykyistä Java-alustaa. MHP-ympäristön laajentamista JPS rajapinnalla pidettiin parhaimpana tapana toteuttaa MHP tulostustuki. Rajapinnan toteuttamiseen ja käyttöön liittyvät yksityiskohdat käytiin läpi ja ratkaisua simuloitiin testijärjestelmällä. Vaikka JPS rajapinnan arvioitiin soveltuvan hyvin tulevan MHP standardin osaksi, ratkaisun standardointia ei analysoitu tarkemmin.

TABLE OF CONTENTS 1 INTRODUCTION ...................................................................................................... 1

1.1 Digital Television as a Software Platform.......................................................... 1

1.2 Printing from Digital Television......................................................................... 1

1.3 Research Objectives............................................................................................ 3

1.4 Report Structure .................................................................................................. 4

2 PRINTING.................................................................................................................. 5

2.1 Overview............................................................................................................. 5

2.2 Print Clients ........................................................................................................ 5

2.3 Printing System................................................................................................... 6

2.4 Printers ................................................................................................................ 7

2.5 Printing Process .................................................................................................. 8

2.6 Print Job .............................................................................................................. 9

2.7 Print API ........................................................................................................... 12

2.8 Print Servers and Printer Adapters.................................................................... 13

2.9 Minimized Printing Process.............................................................................. 14

2.10 Summary ........................................................................................................... 15

3 MULTIMEDIA HOME PLATFORM (MHP) ENVIRONMENT........................... 17

3.1 Overview........................................................................................................... 17

3.2 MHP Standards and Profiles............................................................................. 17

3.3 MHP Applications ............................................................................................ 19

3.4 Graphics ............................................................................................................ 20

3.5 DVB-J ............................................................................................................... 21

3.6 Application Customization ............................................................................... 24

3.7 Input and Output Channels ............................................................................... 25

3.8 Set-top-box Capabilities.................................................................................... 26

4 MHP PRINT SUPPORT........................................................................................... 28

4.1 Overview........................................................................................................... 28

4.2 Print Content Characteristics ............................................................................ 28

4.3 Printer Drivers................................................................................................... 29

4.4 Printer Connections........................................................................................... 30

4.5 Print Support Discovery.................................................................................... 30

4.6 Print Support Architectures............................................................................... 31

4.7 Implementation Analysis .................................................................................. 36

4.8 Summary ........................................................................................................... 38

5 JAVA PRINTING TOOLS....................................................................................... 39

5.1 History of Print Support in the Java Platform................................................... 39

5.2 Platform printing in Java 1.1............................................................................. 39

5.3 Java 2D Graphics Printing ................................................................................ 40

5.4 Java Print Service (JPS) API............................................................................. 40

5.5 Other Java Print Tools ...................................................................................... 44

5.6 Suitability of JPS for MHP Environment ......................................................... 44

5.7 Summary ........................................................................................................... 46

6 PRINT SUPPORT BASED ON THE JAVA PRINT SERVICE (JPS) API ............ 48

6.1 Overview........................................................................................................... 48

6.2 Included JPS API Classes ................................................................................. 49

6.3 MHP Specific Extensions to JPS ...................................................................... 51

6.4 JPS Support Discovery ..................................................................................... 54

6.5 Test System....................................................................................................... 54

6.6 Summary ........................................................................................................... 59

7 CONCLUSIONS....................................................................................................... 61

7.1 External Print Server vs. Platform service........................................................ 61

7.2 Print Support Based on the Java Print Service API .......................................... 61

7.3 Future Directions .............................................................................................. 62

8 SUMMARY.............................................................................................................. 63

REFERENCES ................................................................................................................. 64

APPENDIX 1: JPS PRINT DIALOG............................................................................... 68

APPENDIX 2: JPS4MHP API.......................................................................................... 69

APPENDIX 3: SIMPLEPRINT AND XLETCLIENT..................................................... 72

1

1 INTRODUCTION

1.1 Digital Television as a Software Platform The digitalization of television has had a massive impact on the broadcasting infrastructure as the old analog broadcasting network has been replaced by a digital one. The development of the television network requires changes also to the television receiver equipment at homes. In order to receive the digital broadcast stream, a household needs either a television set capable of decoding the digital TV signal directly or has to augment the old analog television with a separate device that transforms the digital signal into an analog one, commonly referred to as a set-top-box.

The primary purpose of television is still to receive the broadcast stream and display the TV image to the viewer. However, the digitalized TV stream along with new receiver equipment has made it possible to widen the functionality of the television. The digitalization of television has brought interactive applications to the TV and turned the television receiver into a software platform.

1.2 Printing from Digital Television

1.2.1 Printing as Information Sharing

The new role of television makes the television a system capable of processing information along with other devices such as PCs, mobile phones, PDAs and digital cameras. The experience from the other devices shows that there is often a need to share information between the devices; for example, most advanced mobile devices typically offer some possibility to synchronize their data with a PC.

The need to share information applies also to the digital television. The current digital television standards have not yet taken this aspect into account. The television has traditionally been only a receiver, not a transmitter. The new digital television does introduce a return channel, which makes a two-way communication and access to the Internet possible, but its primary purpose is to allow the interactive applications to communicate with the services associated with the broadcasting network. The return channel opens up new possibilities for the kind of services that the television can offer, but information sharing has not been its primary design goal.

On the other hand, the other devices mentioned earlier have various kinds of data channels that allow them to connect with other devices. PCs have traditionally had many I/O ports that are used to connect with various kinds of peripherals like keyboards, displays and printers. Mobile devices like cell phones and PDAs support wireless communication methods like IrDA and Bluetooth /6/ whereas a laptop may use WLAN.

This study examines printing from the digital television. Printing can be thought of as one of the possibilities for information sharing. Printing from a digital television receiver includes the

2

transmission of the information to a printer that transforms the information into a paper form. Printing frees the information from being bound within the television. Regardless of the increase in the amount of electronic information, paper is still a preferred medium for storing information in many situations.

The thesis is part of the project “DigiTVtoPrint: Convergence of Digital Television and Printed Product with Home Media Center”, a collaborative effort of the HUT Media Technology Laboratory and VTT Information Technology. The project studies both technical and business issues relating to printing in the digital television environment.

1.2.2 Printing Scenarios

The applications of the digital television could be virtually any kind of applications. One can easily imagine application domains where the ability to print would be usable. The following table gives a few examples of hypothetical applications that could utilize print support.

Table 1. Example Applications Requiring Print Support

Application Printing need

Bank application The receipt of a payment needs to be archived in paper form.

Service that sells tickets to movies, concerts or other events

The print copy of the ticket gives the person access to the event.

Browser that shows details of the apartments offered for rent.

The details need to be reviewed when the tenant applicant goes to see the apartment.

Coloring application for kids The picture has to be printed so that it can be colored with e.g. crayons

Recipe delivered as part of a cooking show

The recipe is printed so that it can be read in the kitchen when preparing the meal.

The examples show that given the necessary printing technology, it seems probable that the printing support would be utilized. Of course, factors like ease of use and associated expenses affect the popularity of printing solutions.

Naturally, all the printing needs can not be estimated beforehand. The idea of an application running in a television is still new and it is not known what kind of television applications will become popular. It is easy to imagine the conversion of current PC and Internet applications to the digital television environment, but one must recognize that the special characteristics of television might give birth to totally new kinds of applications. For example, a television is used traditionally for relaxation and entertainment whereas a PC is used more for working. At

3

home, a television is commonly placed so that many people can view it simultaneously, whereas a PC is usually used alone.

1.2.3 Multimedia Home Platform (MHP) and Printing

Multimedia Home Platform (MHP) /14/ is an open standard that defines a model for interactive television applications. The standard has been developed by the Digital Video Broadcasting (DVB) group /9/ and has been adopted by many countries, mainly in Europe and Asia /10/. MHP is an optional extension to other more basic digital television broadcasting standards developed by the DVB group /24/. MHP compatible digital television receivers are capable of running interactive applications, whereas simpler receivers may be able to only interpret the digitized television stream. There are also digital television standards such as MediaHighway, MHEG-5 and OpenTV that provide similar functionality as MHP. /24/

MHP standard defines a common environment for interactive applications. MHP is middleware; a mediator between the resources of the set-top-box hardware and the software applications. The system is based on the Java programming language.

The standard allows the broadcasting of applications. MHP applications are delivered to the digital television receivers in the same manner as the television picture, as part of the broadcast stream. The applications are therefore not permanently installed into the set-top-boxes by default, although the latest versions of the MHP standard make this possible. /14, 15/

A standard is needed to ensure that the different receivers from different manufacturers behave in the same manner. Any MHP application should be able to execute in any MHP compliant system, regardless of the differences between the actual hardware. Application development is easier – a single version of the software can reach a wide audience.

From the interactive applications’ point of view the MHP defines what resources of the underlying system are available and how they can be used. The current versions of the standard do not provide any kind of support for printing, however.

1.3 Research Objectives The purpose of this study is to find ways for adding print support to the digital television. The technical requirements for the print support are identified and the viable implementation alternatives are examined. Literature research is used as the primary research method.

The focus is on the MHP environment. MHP has been selected as the software platform standard in Finland. Therefore most, if not all, digital television applications used in Finland are MHP applications. The goal is to overcome the current lack of printing support in the platform and find solutions that would enable all MHP applications to print.

Because MHP is essentially a large Java API, the MHP print support would be realized in the form of a print API. Therefore one of the research objectives is to find a suitable print API.

4

Since the television is a consumer product the print support should be applicable in home printing; which is contrasted here with commercial printing. Home printing means simply printing in home environment, whereas the latter refers to a scenario where a separate print house produces the print in its own facilities and for example delivers the prints to its customers via mail.

1.4 Report Structure The first part introduces the general issues related to software-based printing and serves as the foundation for analyzing the requirements of the print support.

The characteristics of the MHP environment are presented in chapter 3. The following chapter 4 combines the previous chapters by studying printing in the context of the MHP environment. Requirements for the MHP printing support are defined and possible implementation scenarios are compared.

Chapter 5 is a review of the currently available Java based printing solutions. The most promising printing tool is selected and its use in the MHP environment is then studied in chapter 6. Chapter 6 introduces also a test system that was created for experimenting with a print-enabled MHP environment.

5

2 PRINTING

2.1 Overview Printing is a process where an image – text, graphics or both – is produced either on paper or on some other 2-dimensional surface. A printer is a device that interprets digital information and produces the actual print by applying inks on a piece of paper. In software-based printing the printed content comes from a computer system like a desktop computer, for example. Usually an end user initiates the printing process through some graphical user interface. Of course, an automated software process could start the process also.

The details of real-life printing processes are complex and diverse. A simplified model is defined for the purposes of this document. The model consists of only three logical entities – client, printing system and printer.

Figure 1. Printing overview

The clients are software processes or applications that have the need to print something and the printers represent the actual printer devices. The printing system is a mediator between the two parties and encapsulates most of the software-based parts of the printing process. A printing system typically has multiple clients and it may be connected to several different printers. The roles of the entities are described more thoroughly later.

In this document the focus is on the printing system. Topics such as the interaction between the system and its clients, the supported content formats and the communication between the system and the printers are examined. The physical processes inside the printer machines and the print quality are not covered.

2.2 Print Clients Client refers to a software process that initiates the printing process and requests printing services from the printing system. The client provides the content that needs to be printed – e.g. a document - and specifies parameters that describe how the content should be printed – e.g. number of copies, paper size and page orientation.

Typically the client is an application that the end-user interacts with through a graphical user interface. In such a case the need to print something comes ultimately from the end user, who

6

may also have some preferences on the way the content should be printed. The end user uses the print commands of the application for starting the print process. The application obeys the commands and makes then a print request to the printing system.

A simple example is a user operating a word processing application like MS Word. The user would like to print the current document and uses the user interface of the application for initiating the print process. The application forwards the request to the printing system which in this case would be a service offered by the underlying operating system i.e. Microsoft Windows.

The presence of the end user is not necessary, though. The client could be an independent application making print requests.

2.3 Printing System The term printing system used in this document refers to everything between the client and the physical printer device. A typical printing system is a software module that handles some common tasks involved in printing. Printing systems try to fulfill the needs of the clients, while they must adhere to the restrictions set by the printer devices.

The purpose of a printing system is to make the printing easier for the clients. In principle a client could be directly connected with a printer, but in that case the client must be able to handle all the low level details involved. A printing system may provide the clients with a higher-level interface, which is more straightforward to use and hides the differences between printer devices.

A printing system can enhance the capabilities of the printer. A simple example of this is a printing system that can support more content data formats than the printer by using transformations; the content data is converted into the format understood by the printer in software.

Typically a printing system has multiple clients. Printing is usually a service offered by an operating system and all the applications running on the platform may use the same service. A printing system can implement common functionality that otherwise would has to be implemented in all of the applications separately.

The printing system is the most complex entity in the model depicted in Figure 1. It may consist of multiple software processes that might be hosted on different computers. On a PC that is directly connected to a printer the printing system could refer to the printing capabilities provided by the operating system and would be situated on a single computer. If the printer would be a network printer, the printing system could consist of multiple computers. One part of the system would be on the same computer as the client process and respond to the print requests of the client. The requests would then be forwarded over the network to a component on another computer that would actually be connected with a printer. The kind of network printing scenario is utilized by for example Microsoft Windows /23/.

7

At least part of a printing system relies typically on the same system as the clients, because then it can communicate with the clients through a programming interface (API). Print APIs are discussed more thoroughly in Chapter 2.7. Printers on the other hand are here viewed as independent devices. Printers and printing systems communicate through some data communication channel.

2.4 Printers

2.4.1 Overview

In the model the printer represents the actual physical device that produces the actual print. Inkjet printers are typically utilized in home printing, although laser printers, which are usually more expensive, could also be used. Home printers are typically connected with PCs. Older models might rely on a serial or parallel port, whereas the I/O port in the latest models is usually USB. More advanced models may be equipped also with for example Ethernet, WLAN or Bluetooth support. /17, 13, 21/

Printers can be accessed also from other devices than PCs. For instance, special photo printers can print images directly from digital cameras. This is achieved with e.g. the PictBridge /7/ printing standard which enables cameras and printers to communicate with each other. /17, 21/.

2.4.2 Printer Installation and Printer Discovery

A printing system is typically aware of the presence of the available printers. Printer installation is a process where a new printer is introduced to the printing system. The communication channel between the printer and the printing system is established and the necessary settings are configured. After the installation the printing system is capable of forwarding print requests to the printer.

If the printing system relies on a PC, the connection to the printer is relatively stable. Both PCs and printers are usually kept at fixed locations and the printing system uses the same set of printers every time.

The situation is different for mobile devices. Mobile devices access the closest print service instead of relying always on the same printer /4/. In such scenarios the printing system, which relies now on the mobile device, is connected to the printer only for the duration of a single print job. The printer installation must be an automated and simple process. A more appropriate term would be printer discovery.

2.4.3 Printer Drivers

Printing systems need to be compatible with various kinds of printers. For this a printing system typically uses a printer driver /49/ for controlling a printer device. Printer driver is usually a small application that can control and feed data to a particular kind of printer, an

8

adapter that makes a printing system and a printer work together. Drivers are typically customized for a certain printing system and a certain printer. Printer vendors may provide several drivers that make it possible to use their printers on the most popular platforms like Microsoft Windows and Macintosh, for example /17, 13, 21/.

Printer driver is configured during the printer installation. On PCs the driver may be provided e.g. on a floppy disc or CD-ROM or fetched from the Internet. Also, because hard disc space is usually abundant, the operating system may readily contain the printer drivers for the most popular printer models.

Printer drivers might complicate things for mobile devices that need to connect to various kinds of printers relatively quickly. The device might not afford to store the most common printer drivers in advance and the extra step of locating an appropriate driver slows the printer discovery process. Mobile devices would benefit from a printing method that does not require special printer drivers. We use the term driverless printing for referring to printing solutions that allow clients to print to several printers without installation of device specific drivers.

We define the term direct printing as a special case of driverless printing where the printing process involves only the transfer of a document in a suitable format to a printer. If the printer supports the content format, it prints the document, otherwise nothing happens. A driverless printing solution could include also other communication like the specification of parameters and signaling of error conditions. An example of a printer supporting direct printing is HP Color LaserJet 5550 dtn /18/ printer, which supports direct printing of PDF files.

Driverless printing simplifies the printing process but is successful only if a certain driverless printing solution becomes widespread enough so that the print clients can rely on it alone. In practice printers have differences and incompatibilities and printer drivers are usable in overcoming them. A driver-based printing solution promotes support for a larger set of printers.

2.4.4 Printer Monitoring

In addition to submitting print jobs to the printer, the printing system needs to be aware of the status of the printer. For example, a printer may be ready to accept new jobs, be busy or be in some error condition that requires human intervention.

2.5 Printing Process A typical printing process consists of approximately the following steps:

1. A client has something to print and initiates the process

2. The client negotiates the print parameters with the printing system

3. The client submits the print request to the printing system

9

4. The printing system may perform some transformations and finally submits the print job to the printer

5. The printer produces the print

The parameter negotiation in step 2 is based on the features that the printing system can support and typically involves the end user. Page orientation and the number of copies are examples of print parameters. A print request or print job encapsulates both the content to be printed and parameters that describe how the content should be printed. The print job might be monitored during the process; the printer might give feedback to the printing system about its state and the printing system might give feedback to the client about the progress.

2.6 Print Job

2.6.1 Overview

Individual printing tasks are often referred to as print jobs or print requests /23, 38/. Essentially a print job consists of two things:

• The content to be printed

• Parameters specifying how the content should be printed

A print job can also have an associated state that tells for example whether the job is on queue, is currently under processing, has already been finished or has been canceled.

Print jobs originate from the print clients, who submit them to the printing system.

2.6.2 Content Delivery Methods

A client can deliver the content data to the printing system in many ways, for example:

1. Page imaging – the client draws the content on the pages by using rendering commands similar to those used for drawing the graphical user interface of an application.

2. Document printing – the client has a document in a suitable data format and it is sent to the printing system.

3. Pull printing – a version of document printing where the client gives only the location of the document to the printing system. The printing system fetches the document by itself. The location is typically expressed in a form of an URL. The document can reside on the Internet instead of the computer hosting the client. /50/

In page imaging the printed content is created dynamically during the printing process. Printers do not usually understand the rendering commands directly so the printing system must translate the commands into a data format understood by the printer.

10

Page imaging is a widely used method for providing the content data. For example, the printing on the Microsoft Windows platform is based on the Windows GDI which uses page imaging as the primary approach for printing /65/. Rendering commands can typically be given on a pixel-level precision, so page imaging allows the clients to specify the layout in a very detailed manner.

Document and pull printing are supported by for example the Java Print Service (JPS) API /38/. In document printing and pull printing the content may have been generated before the process and are transferable between different computer systems. Depending on the format, the document can either be fed directly to the printer or it can be transformed into a suitable format by the printing system. Both methods require less application programming and computing resources because sending a document or link to the printing system can be achieved with fewer steps than generating the pages through rendering commands.

Pull printing is best fit for very low-profile devices. The client does not necessary have to handle the document in any way. The document and the part of the printing system that fetches the printed document can be located on other computers than the client, so the client needs only to operate with the link. /50/

2.6.3 Content Data Formats

Content data formats are important in document printing and pull printing. In page imaging the content is described with a set of programming code which is not here considered as a data format.

In principle a printing system could support any kind of format. The only requirement is that the printing system can transform the content into a format supported by the printer. Printers may also readily support several formats, so the printing system does not necessary have to perform any transformation at all. Examples of common formats include:

• Plain text

• Various image formats (e.g. bitmap, GIF, JPEG, PNG)

• Page description languages

Page description language is a common term used for the data formats designed for printing. Adobe’s PostScript Language (PS) /2/, Portable Document Format (PDF) /1/ and Hewlett-Packard’s Printer Control Language (PCL) /45/ are examples of commonly used page description languages. Printers typically support some page description language natively.

A printing system could support also more abstract formats like Hypertext Markup Language (HTML) /52/ for instance. An HTML document describes the content of a web page, which does not have fixed dimensions like a paper has. HTML does not specify the exact visual outlook; the browser is given some freedom in rendering the web page on screen. A printing system readily supporting the printing of HTML documents would be usable because of the

11

vast amount of HTML content available on the net. On the other hand, in order to print an HTML document the content has to be fitted on the physical page or optionally split to multiple pages. Such issues increase the amount of processing that a printing system has to perform.

2.6.4 Print Job Attributes

A client might have special preferences on how the content should be printed. For example, the client might want to print single-sided or double-sided pages, print multiple copies or specify the page orientation.

These kinds of preferences are attached to the print job and called print job attributes. The available attributes depend on the printing system and the printer. A printing system can introduce new attributes that are not directly supported by a physical printer. The printing system maps the additional attributes to the printer-supported attributes in software.

2.6.5 Print Queues and Spooling

Printing is a time consuming process and a printer can print only a single job at a time. Simultaneous print jobs must therefore be queued. Because printers do not usually have large memory buffers the maintenance of the queue is often the responsibility of the printing system.

When a printing system receives a print job, it usually spools the job. Spooling means writing the job data first on a buffer, either a memory-buffer or a buffer on the hard-drive, before submitting the data to the printer /51/. Spooling is closely related to the print queue management; adding a job on a queue typically includes spooling of the job.

2.6.6 Print Job Monitoring and Control

Print jobs are tasks that take time to process and may fail. The successful completion of a print task depends largely on the physical print device. For example, it takes time to transfer the printed data to the printer and produce the print, the printer may still be printing a previous job and there may be paper jams. Also software processes may take time or fail – there might be network problems, for example.

The usability of a printing system would be improved if the system could give the client some feedback on the print job. Information about whether the job was completed successfully or failed would probably be the simplest feedback. A printing system may also support print job monitoring, meaning that the client can monitor the progress of the print job.

Print job control means that the client can change the status of the print job during printing process. Print job control could include the possibility to pause, resume and cancel print jobs, for example.

12

2.7 Print API

2.7.1 Overview

The Print API is the public interface of a printing system. Software components expose their functionality to other programs through application programming interfaces (API). The API defines how other programs interact with the component on the programming language level. In this case the other programs are the clients that access the printing service. In the printing model presented earlier (Figure 1), the print API is an interface between the client and the printing system.

Because a printing system may have several clients, the API of the system becomes important. The API must be flexible enough to serve the needs of different kinds of clients. Also, the API must be relatively stable – large changes can not be made to the API if there are a large number of applications depending on the API.

2.7.2 Common Characteristics

Print API gives the clients methods for using the services of the printing system. At the same time it also defines the functionality that the printing system offers. Usually the client applications are aware of only the features of the API that they are programmed against and can not for example discover new functionality during execution /12/.

Therefore most printing related aspects are visible in a print API in a form or another. For example, a print API could define:

• how the clients form a print job and submit it to the printing system,

• what content delivery methods can be used,

• the data formats and print job parameters that are available,

• how the print job parameters are negotiated and how the printer is selected and

• how the print job can be monitored

Of course, every printing system might not have all the features and a print API can be simpler.

2.7.3 Print Dialog

A print dialog is a graphical user interface component that the end user can use for expressing her print job parameters. A printing system may provide a standard print dialog that can be used by clients that need to interact with the end user. The dialog simplifies application programming as the clients do not have to provide the dialog by themselves.

Print dialog support is usually visible in the print APIs in some way so that the applications may control when the dialog is displayed to the user. The operating systems usually include a

13

native print dialog. As an example, the Microsoft Windows provides a standard print dialog that gives the user the opportunity to choose the printer and the print parameters.

2.8 Print Servers and Printer Adapters Print server is a commonly used term for a device that receives print requests and communicates with a printer. Print servers are used for example in network printing where a printer is accessed by all the computers in a LAN network. In such a case the printer may be directly connected to the LAN or through a print server that communicates with the other computers. For example, the network printing capabilities in the Microsoft Windows operating systems support both alternatives /23/. The print server would be implemented by a desktop computer running for example Microsoft Windows Server 2003 or Windows XP professional operating system /23/. The arrangement is visualized conceptually in Figure 2.

Figure 2. LAN printing with a print server

Various communication methods are used. The print clients and the printing system would communicate through an API. The PC and the print server would be connected via e.g. Ethernet connection, whereas the print server and the printer could be connected via e.g. parallel, serial or USB port. In the above scenario the printing system can be thought to be a distributed system; both the PC running the print clients and the print server are semantically part of the printing system.

A print server can also be implemented by a special device that is plugged into the printer instead of a desktop computer. For example Hewlett-Packard provides print server components /20, 16/ that enhance the printer’s communication capabilities. A printer that is normally connected only via the USB or serial port can be made for example Ethernet-enabled by attaching the print server to the printer. Also support for wireless connections such as WLAN or Bluetooth are possibilities. These kinds of print servers are sometimes called printer adapters. /20, 16/

14

2.9 Minimized Printing Process

2.9.1 Overview

A printing process does not have to include all the features presented so far in order to be usable. A more streamlined process could be needed for situations where the computing resources are scarce, for example. The essential functionality is identified by sketching a minimized printing process.

The most essential part of the printing process is the delivery of the printed content to the printer. There must be some content in a printable form and this content must be delivered to the printer in order to be printed. It should be easy for the client to either create or obtain the printed content. The client must be able to communicate the printed content to the printer through some connection. The printing system could serve as a simple mediator between the client and the printer or the client could be directly connected to the printer.

It is obvious that if the client wants something to be printed, the printer must be told what to print. This requires that there is some kind of a connection between the client and the printer that the client can use for delivering the content to the printer.

Other print-related issues can be considered optional:

• No content transformation – the client can provide the content in a format readily understood by the printer. The printing system should not have to do any transformations.

• No print job attributes - the printer can print with its default settings.

• No printer monitoring or print job monitoring – it is not critical for the client to know whether the job was successful or not.

• No spooling – the print job can be fed directly to the printer.

The features left out minimize the amount of exchanged information and processing performed by the printing system.

The possibility to cope with less communication may be welcome in situations where heterogeneous systems need to be integrated easily. An example of this could be a situation where a system is required to work with every possible printer and the protocols for communicating with printers are very different. The system is easier to implement if only a minimum level of communication needs to be supported.

Reduction in the amount of processing – mainly content transformations and spooling - is usable and required in environments where computing power and memory are scarce.

Next, an example of a printing process that resembles the minimized process is presented.

15

2.9.2 Bluetooth Basic Printing Profile

Bluetooth /6/ is a wireless communication method for short range connections. Bluetooth can be used for connecting various devices like mobile phones, PCs, printers and digital cameras. Bluetooth Basic Printing Profile defines a way for various Bluetooth devices to send print jobs to Bluetooth-enabled printers. /6/

Basic Printing Profile defines the roles of the printer and the user of the print service. It requires very little from the client. The client device can discover the printer through the standard service discovery methods of Bluetooth. The client does not have to install any printer drivers. The printed content is simply pushed to the printer via the Bluetooth connection. No parameters are provided; the printer is obliged to print with its default settings. The printer does not have to give any status information or error messages back to the client. /5/

The only mandatory content format that must be supported is XHtml-Print /53/. XHtml-Print is a high-level page description language based on XHtml and Cascading Style Sheets (CSS). It is designed for situations where the handling of traditional page description languages requires too much processing power or memory. The content is considered more important than the exact visual outlook – the printer is given some freedom in rendering the document. /5, 53/

The Bluetooth printing solution shows how printing can be achieved with very resource-limited devices. The printing process is minimized to the transfer of the print content, everything else is left out. The system does not include a printing system if the printer understands Bluetooth and XHtml-Print natively. The Basic Printing Profile support can also be added to a printer with a Bluetooth printer adapter /20/.

2.10 Summary Software based printing was analyzed in the context of a model consisting of three entities: a client, a printing system and a printer. Clients are applications that want to print something and printers are devices able to produce the actual print. A printing system serves as a mediator between the two entities and its main purpose is to enhance the capabilities of a printer and provide the clients with a higher-level interface in the form of a print API, for example. Printing systems also hide the differences between the various printer devices from the clients.

The printing process is based on the concept of a print job that encapsulates the print content and the print parameters. Printing systems may typically support three kinds of content delivery methods: page imaging, document printing and pull printing. Page imaging was based on creating the printed pages on the fly with programming-language level rendering commands, whereas the other two rely on the visual data formats such as image formats or page description languages.

16

After a client has defined the print content and the parameters in an appropriate form, it submits the print job to the printing system. Print system gradually transfers the job to a printer after applying perhaps some transformations.

The transfer of the print content from the client to the printer was identified as the most important part in printing. If the printer is advanced enough, the printing can be achieved without the printing system, as in the Bluetooth Basic Printing Profile. However, printing systems are necessary if printers with varying properties need to be supported.

17

3 MULTIMEDIA HOME PLATFORM (MHP) ENVIRONMENT

3.1 Overview MHP (Multimedia Home Platform) is a standard created by the Digital Video Broadcasting (DVB) group /9/, a consortium that has been developing various digital television related technologies for several years. DVB has for example standardized how digital TV signals are transmitted over cable, terrestrial and satellite networks. MHP complements the digital broadcasting technology by providing a way to transmit interactive applications within the TV stream and specifying how the applications are executed in a digital television receiver. /24, 10/

The MHP standard is to be implemented by the digital television receiver manufacturers. The standard defines the software environment that the receiver device must offer. A typical MHP implementation is a set-top-box with MHP capabilities, although the MHP support could be integrated directly into a digital television set or the system might be implemented on a PC. MHP is important also for application developers and broadcasters, as it also describes the properties of MHP applications and the way they are delivered to the receiver via broadcast.

MHP is only one of the competing standards. Other similar technologies include MediaHighway, MHEG-5 and OpenTV. In general, MHP and other DVB specifications have been adopted mainly in Europe and Asia. MHP has been selected as the interactive application standard in Finland. /24/

3.2 MHP Standards and Profiles The Digital Video Broadcasting (DVB) group has been developing MHP since 1997 /25/. MHP has currently two standards tracks: MHP 1.0 and the more advanced MHP 1.1. The latest versions of the standards are MHP 1.0.3 /14/ and MHP 1.1.1 /15/, which have both been standardized in June 2003.

MHP uses the concept of a profile for describing the capabilities of an MHP implementation. Device manufacturers may choose to implement different profiles and therefore provide varying levels of functionality. The profiles and their most important functionalities are described in Table 2. The profiles are additive: each profile only provides more functionality than is available in a previous profile.

18

Table 2. MHP Profiles /24/

Profile Main functionality

Enhanced Broadcast profile

The core platform functionality. Enables the digital television receiver to execute interactive applications.

Interactive Broadcast profile

Provides an interaction channel (return channel) that supports TCP/IP communication. The interaction channel enables more interactivity as the applications may have one-to-one conversations with various services in the network.

Internet Access profile Brings various internet technologies to the television. The interaction channel must support HTTP and SMTP protocols and the device must be equipped with native web and email clients. Applications can be downloaded also via the return channel and can be cached on a hard disc.

The profiles have a correlation with the MHP standards. MHP 1.0 specifies the Enhanced Broadcast and Interactive Broadcast profiles. MHP 1.1 introduced the Internet Access profile and refined the previous profiles slightly, mainly the Interactive Broadcast profile. Table 3 highlights the situation. /14, 15/

Table 3. Standards and Profiles /15/

MHP 1.0 Enhanced Broadcast profile 1

Interactive Broadcast profile 1

-

MHP 1.1 Enhanced Broadcast profile 2

Interactive Broadcast profile 2

Internet Access profile 2

Backwards compatibility is ensured between profile levels 1 and 2. Enhanced Broadcast profile 2 only introduces new features that are not present in profile 1; it does not change the existing semantics or features. An application created for a level 1 MHP receiver profile will work also in a corresponding level 2 MHP receiver. /15/

19

The term MHP 1.0 compatible is hence used of receivers that support either the Enhanced Broadcast profile 1 or Interactive Broadcast profile 1. MHP 1.1 compatible receivers may implement any of the level 2 profiles.

3.3 MHP Applications

3.3.1 Broadcasted Applications

Broadcasting is the primary method for deploying MHP applications. Application code is encoded within the digital television stream and delivered to the receivers with the same way as the TV programs. Applications can be thought of as a kind of interactive TV programs or interactive extensions of a TV show. A TV channel is called a service in the DVB vocabulary, and each service may have a set of applications that are associated with it. The application code and other meta-data are encoded to the same stream with the video and audio tracks of the service. /24, 14/

Every service contains an Application Information Table (AIT) that describes the applications currently available. The information in the AIT tells the receiver which applications should be started automatically and which are launched by the user. When an application is launched, the application code is loaded from the service stream and the application state is initialized. /24, 14/

The content of AIT may vary depending on the program that is currently being broadcasted. This arrangement makes it possible to bind applications tightly to the context of the current TV show. On the other hand, only the applications relating to the current channel can be started. When the user switches to another channel, the set of applications is changed. Currently running applications are stopped and unloaded, unless the same application is available in the other channel also. /24, 14/

By default, the applications are not stored or installed into the MHP systems. Application code is read from the stream and started when needed. Special update methods are not needed – a broadcaster may simply place a new version of the application in the stream and the change becomes effective immediately. /14, 15/

MHP 1.1 introduced new application deployment methods. Interactive Broadcast 2 and Internet Access 2 profiles must support application download also via the interaction channel. /24/

3.3.2 Application Models

MHP defines two complementary application models: DVB-J and DVB-HTML. DVB-J is the primary application model of MHP. It is based on the Java programming language and it must be supported in all the profiles. DVB-HTML is a newer model defined by the MHP 1.1 standard /15/. DVB-HTML is optional: MHP 1.1 compatible implementations may choose to support it.

20

DVB-HTML was added to complement the DVB-J model. DVB-HTML applications are based on XHTML and are essentially a collection of web pages. DVB-HTML is intended for relatively static, information-centric applications, whereas applications requiring a highly interactive GUI are best implemented with DVB-J. /24, 15/

Most of this study will be concerned with DVB-J, which is described more thoroughly in Chapter 3.5.

3.3.3 Stored Applications and Stored Services

All MHP 1.1 compatible implementations must support stored applications, regardless of the profile /15/. Stored application are cached or stored into the MHP system to minimize application launch time. The application code can be loaded faster from the local system than from the broadcast stream. Stored applications behave otherwise exactly the same as broadcasted applications. They are still bound to the currently selected service and can be launched only if the application is listed in the AIT. Applications may be stored proactively by the MHP implementation or a request for caching can be signaled in the AIT. /24/

MHP 1.1 introduces also stored services, which are a collection of stored applications. Stored services are analogous to broadcasted services i.e. a channel, but a stored service is not a copy of a broadcasted service. A stored service can be selected as the current service with the same way as broadcasted services, after which the applications of the stored service become usable. /24/

3.3.4 Native Applications

The MHP system may contain native, platform-specific applications in addition of the regular MHP applications. As an example, a set-top-box might have a native Electronic Programming Guide (EPG) that would compete with an Xlet-based EPG. /24/

The Internet Access profile in MHP 1.1 requires that the system is equipped with three native applications that are used for accessing internet services: a www browser, an email client and a Usenet news client. /15/

3.4 Graphics MHP defines that the receiver must support at least three different presentation layers /15/:

1. Background layer capable of displaying a static image

2. Video layer for displaying the MPEG stream

3. Graphics layer for displaying the application graphics

A receiver could have additional layers like two graphics layers for example. The situation is visualized in Figure 3.

21

Figure 3. MHP display layers /15/

Applications may draw on the graphics plane. The minimum resolution is defined to be 720x576 pixels. In addition, due to the properties of television sets, around 5% of the display may be outside of the screen. Therefore the visible area may often be quite small when compared to modern computer screens, for example. /15/

3.5 DVB-J

3.5.1 Overview

DVB-J is a Java framework that forms the core of MHP. In order to support DVB-J, the MHP implementations must be equipped with a Java Virtual Machine (JVM) and a set of Java libraries that provide a standard environment for the DVB-J applications to live in. Figure 4 shows an overview of the situation.

22

Figure 4. MHP architecture /47/

DVB-J applications are special Java applications called Xlets that run in the digital television receiver. Xlets are conceptually similar to Java Applets, which are Java applications executed in a browser. Both applications differ from normal stand-alone Java applications in that they live in a well-defined container. The Xlet application model is defined by the JavaTV API /41/. Every Xlet application must implement the javax.tv.xlet.Xlet interface that provides for example a way for the container and application to interact with each other. /24/

Xlets can for example draw on the screen and receive user input and can be used for various purposes. Electronic Programming Guides (EPG), text television browsers and games are examples of Xlet applications. /24/

3.5.2 MHP API

MHP API is a mixture of several different Java libraries. They enable the Xlets and the underlying system to interact in a device independent manner. The system may reclaim resources from the applications, start and stop applications, etc.

The DVB group has reused many existing APIs, which have been glued together by the MHP specific DVB API. The APIs are listed with a short description in Table 4.

23

Table 4. MHP APIs

API Purpose Developed by

Java platform 1.1.8 A subset of the standard Java platform 1.1.8 for various core programming tasks.

Sun Microsystems

JavaTV 1.0 Xlet framework for digital television applications.

Sun Microsystems

Java Media Framework 1.0

Presentation of broadcast audio and video streams.

Sun Microsystems

HAVi 1.1 A graphical user interface component library specialized for the television.

HAVi (Home Audio Video Interoperability)

DAVIC 1.4.1 Resource management, MPEG stream handling, etc.

DAVIC (Digital Audio Video Council)

DVB API Various MHP specific APIs not covered by the other APIs.

DVB Project

Every MHP compliant set-top-box will contain an implementation of the interface created by the set-top-box manufacturer. It is designed to be suitable for even small-footprint devices.

3.5.3 Resource Management

Resource management is a major issue in MHP. To ensure that the applications would not exhaust the scarce resources of the system, the control of the resources is left to the receiver hardware. When an application wants to use a scarce resource, it requests it from the system and may or may not be granted permission to use it. Even when permission is granted, the system may reclaim the resource and the application must be prepared to loose the resource at anytime. /14, 24/

On the software level the resource management is implemented by the resource management API, which is part of the DAVIC API in package org.davic.resources. The details of how to reserve a resource depend on the resource in question, but the package defines a general resource notification API, which is used for notifying the user of a resource that it must give up the resource. /14, 24/

In the model, applications do not usually have direct access to the Java object that represents a scarce resource. Instead, they access the resources through proxy objects, which implement the interface org.davic.resources.ResourceProxy. /14, 24/

24

3.5.4 Application Encapsulation

Xlets are very strictly isolated from each other. The MHP standard requires that every Xlet is loaded with its own classloader, which ensures that an Xlet can not interact directly with another Xlet and that application classes of two separate Xlets do not get mixed up. /24/

Although Xlets generally are independent, there might be cases where some cooperation is needed. For this the MHP allows two Xlets to communicate indirectly by using the Java Remote Method Invocation (RMI) technique. /24/

3.6 Application Customization

3.6.1 Overview

In this context the term application customization means modifying an Xlet based on the characteristics of a certain user or MHP system. By default, MHP applications are delivered through broadcast, which makes customization difficult as the same application code is delivered to every receiver. However, application customization is important in situations where the preferences of the user need to be taken into account or when an Xlet needs system-specific information. Application customization may be relevant in printing because the printer is a local device and different MHP receivers could be connected to different kinds of printers.

3.6.2 Persistent Storage API

MHP offers the Persistent Storage API for storing application specific information on the underlying system. The API is required in all of the profiles and consists essentially of the Java IO API together with a few classes from the DVB API. The information stored is either specific to a certain application or can be shared among applications that are developed by the same organization. /15/

Persistent Storage API could be used for application customization purposes. An Xlet could query the preferences from the user and store the results into a file. The preferences can then be read in the next execution of the application.

Although the API is obligatory for all MHP receivers, much can not be said about the amount of available storage space. The standard specifies only the minimum size of the storage, which is as little as 4096 bytes /15/. In the worst case the storage is therefore almost non-existent. As with other resources, the receiver middleware has the ultimate control over the storage. The system may choose clear parts of the storage in order to free space for other applications at any time. The Persistent Storage API is not suitable for storing critical information; applications must hence be prepared to loose the data.

25

3.6.3 System Properties

In Java, the java.lang.System class provides a simple way to access system-specific information in the form of system properties. System properties are simple name-value pairs that are specific to the current system. MHP uses system properties for e.g. storing the information about which profile the system implements and what optional features are supported.

However, MHP prohibits the Xlets from altering system properties – invocation of the method java.lang.System.setProperties() will always result in exception /15/. There is no other method for changing system properties programmatically in Java 1.1.8 /37/ – for example, the method java.lang.System.setProperty() was introduced only in J2SE 1.2 /32/.

System properties are therefore read-only and can be used only for signaling the Xlets about the characteristics of the system.

3.6.4 User Preferences API

The User Preferences API, specified in the package org.dvb.user, gives Xlets access to predefined user preferences. Standardized preferences include for example user language, country code and default font size. Xlets may also change the values of the predefined preferences, but they can not define new ones. /14/

The User Preferences API enables therefore a kind of standardized Xlet customization but is not a general purpose customization tool.

3.6.5 Summary

MHP provides very limited support for Xlet customization. System properties and the User Preferences API allow only customization based on predefined properties. The Persistent Storage API is the only method that allows applications to store arbitrary preferences, but the applications must be prepared to loose the data.

3.7 Input and Output Channels

3.7.1 DVB Stream

The primary input channel of digital television is naturally the television stream. In addition to the video and audio streams, the stream contains also data streams, which are used to broadcast the application code and associated data to the receivers.

The stream is of course a one-way stream and the same content is delivered to all the receivers, as implied by the term broadcasting. This has some limitations on the applications – the data can not be customized for individual users and the TV stream can not be used for two-way communication.

26

3.7.2 Interaction Channel

The Interactive Broadcast and Internet Access profiles require that the receiver is equipped with a data channel that supports TCP/IP protocol /14/. This interaction channel is often referred to as the return-channel. The interaction channel opens up new possibilities for the applications as they can now communicate with various services.

MHP doesn’t define the properties of the interaction channel any further. The channel could be implemented by for example an analog modem, ADSL, cable or Ethernet connection.

3.8 Set-top-box Capabilities

3.8.1 Overview

Set-top-boxes are devices that convert the digital television stream to an analog one. The analog stream is then forwarded to a normal analog television. This way the old television can be used in viewing also the digital television image. The MHP functionality is most often built into the set-top-boxes, so the properties of the set-top-boxes are important in understanding the MHP environment.

The MHP standard tries not to state anything explicit about the hardware requirements of the MHP implementations, because it is important to give the device manufacturers some freedom. However, in many cases the implementation of an MHP feature implies something about the hardware that is needed.

3.8.2 Memory and CPU power

Instead of specifying the exact memory or CPU performance measurements of a set-top-box, the MHP standards /14, 15/ specify tasks that a set-top-box must be able to perform. The tasks include the loading of a PNG image or loading a certain amount of Java class files or initializing a Java object array of a certain size.

To give a rough view of the capabilities, it is understood that a set-top-box conforming to the Internet Access profile should have at least 150-200 MHz CPU and 32 MB RAM /30,8/. The minimum performance requirements for Enhanced Broadcast and Interactive Broadcast profiles are something less, around 100 MHz CPU and 16 MB RAM /30,8/.

3.8.3 Persistent Storage

Persistent storage can be very limited in the set-top-boxes, especially in MHP 1.0 compatible devices, because the only feature necessitating such a storage is the Persistent Storage API and the minimum storage size required by the API is very small. MHP 1.1 /15/ introduces stored applications i.e. applications that can be stored into the set-top-box. The stored application support is likely to increase the persistent storage available in the MHP 1.1 compatible set-top-boxes, but the exact amount is not known. /14, 15/

27

A set-top-box might support recording of TV programs. The receiver could be equipped with for example a hard-disc that is large enough to store hours of MPEG stream. The persistent storage would then be abundant.

3.8.4 Input and Output Channels

A set-top-box will contain necessary ports for receiving the digital television stream and connecting the device with e.g. a normal television. Receivers supporting the Interactive and Internet profiles will be equipped with an implementation of the interaction channel, e.g. a port for a PSTN modem, Ethernet or ADSL connection /15/.

Other data I/O ports could be provided by the set-top-box vendor. They would be inaccessible to standard Xlets, however, because the MHP does not provide any API for accessing them.

28

4 MHP PRINT SUPPORT

4.1 Overview The aim is to find a general solution that gives MHP applications access to printing services. Because the focus is on home printing, a printing system that allows the set-top-box to be connected with a local printer is needed. The clients of the printing system would be DVB-J applications i.e. Xlets. The situation is visualized conceptually in Figure 5.

Figure 5. MHP print support

Also applications native to the platform could use printing services. DVB-HTML applications however are more passive and would not make printing requests by themselves. On the other hand, the browser used for viewing the DVB-HTML applications could want to print e.g. XHTML pages.

4.2 Print Content Characteristics

4.2.1 Performance Requirements

Digital television could be used for printing virtually any kind of information. The requirements for the quality, reliability, size and other such aspects of the printing process depend mainly on the applications and can not be derived from the platform characteristics. Of course, it is preferred that the printing system does not become a bottleneck and that it should scale for as high-quality printing as the printer and the resolution of the content allow.

4.2.2 TV Screenshot

In order to take a screen capture and print it, an application would need to have programmatic access to the MPEG-data. The MPEG decoder in a set-top-box is usually hardware based, which can make it difficult to access the MPEG data in any way.

In addition, MHP uses the Java Media Framework (JMF) API /36/ as an interface to the decoder. The JMF version 2.0 contains a class FrameGrabbingControl that is capable of grabbing a still picture from a video clip. Unfortunately the JMF version used by the MHP is 1.1 /24/ and it does not contain a similar support for frame grabbing. /36/

29

It seems therefore impossible to take a screen capture of the TV image in the MHP environment. The applications may only print the content in the graphics layer or other content that can somehow be manipulated by the Xlets.

4.2.3 Print Layout for the Content

When presenting information to the user, Xlets format the content into a layout that fits the television. The resolution of the TV screen and the viewing distance are most important factors affecting the way content is displayed.

The size of the graphics layer as specified by the MHP standard is 720x576 pixels /14/ which is less than the resolution commonly used in desktop computers. The actual visible area can be even smaller due to the limitations in the television sets /14/. Also, the distance for watching television is typically larger than the distance between a computer user and a monitor; a television viewer sits on a couch, computer user sits on a chair pretty close to the display. Because of this the text size in television needs to be larger than on PC.

The effect of these characteristics is that a screenshot from an MHP application is not visually the best format for displaying textual information on paper. The proportions of an A4 paper are different from the screen dimensions and the text size is usually smaller. Because the resolution supported by the printers is much higher than in the television, much more information can be fitted on a single piece of paper than on a TV screen.

The content should therefore be reformatted for printing. MHP applications could either do the formatting programmatically or the content provider could offer a separate print version of the content. The print version would be retrieved from the DVB stream or via the interaction channel when needed and printed.

The advantage of a downloaded print version approach is that the reformatting could be done solely on the server-side and the CPU consumption on the MHP receiver could be reduced. The print version can be distributed in a format that is directly supported by the printing system. Furthermore, the software environment on the server-side is not as restricted as the MHP, so it is likely that the transformation of content to the appropriate data format is easier to implement on the server-side.

4.3 Printer Drivers Printing from a digital television has many similarities with printing from a home PC. MHP receivers and PCs both harness a general software-platform, although the MHP environment is much more restricted. Both devices are typically fixed to a certain location at home, which means that the systems use regularly the same set of printers. Therefore the printing support could be based on a solution similar to what is used in PCs.

Printer drivers are common in PC-based printing because they enable a printing system to interact with various kinds of printers. The same applies to MHP printing support. Home users

30

would benefit if they can use their existing printer devices when printing from the digital television.

The drivers are usually platform dependent – a printer driver written for Macintosh will not work in Windows. In order for the MHP printing support to use printer drivers, a general driver interface would need to be designed and the drivers for the different printers would need to be implemented.

MHP systems are built for running broadcasted applications, whereas printer drivers are typically installed permanently into the system. The installation requires a persistent storage to be available. The resource restrictions of MHP devices may also limit the amount of transformations that a printer driver can do. If the printer supports only a very low-level data format, it may take too long for a printer driver to transform the print content to the appropriate form.

Print driver support does not therefore mean that every kind of printer model can be used in digital television printing. There might not be enough interest to implement MHP specific printer drivers or there are not enough resources for the print driver to do its job. Nevertheless, the driver based approach is a good mechanism for achieving greater interoperability.

4.4 Printer Connections In order to print, a set-top-box must have a connection to the printer. The MHP receiver should therefore implement either the Interactive Broadcast or the Internet profile. These profiles support the interaction channel, which could be used for the printer connection.

The interaction channel should be implemented by a LAN port, e.g. an Ethernet port. The LAN support would make it possible to place the set-top-box and the printer into the same LAN. This would allow the set-top-box to access both the Internet and the printer, and optionally also other devices in the LAN.

If the printer would be directly connected to the MHP receiver, it should then support TCP/IP. A simple home printer could be made TCP/IP connectable with e.g. a printer adapter. For example Hewlett-Packard offers such printer adapters for HP printers /16/.

The MHP receiver could also be equipped with additional data ports – for example an USB port or a Bluetooth transmitter – which could be used as printer ports.

4.5 Print Support Discovery Xlets must have means to discover whether the current system has the printing support or not. Xlets need to be interoperable also with regular MHP implementations and accessing a non-existing service causes most likely errors.

MHP uses system properties for describing the optional features of the platform, so the same technique could be applied for print support discovery also. Other alternative is that the Xlets

31

somehow query the printing system directly. The details of this method depend on the way the printing support is implemented.

4.6 Print Support Architectures

4.6.1 Print Server

This section describes various approaches for implementing the MHP printing support. In each of the scenarios presented, the MHP system could be either directly connected to a printer or be connected to a separate print server. The print server is required in situations where the capabilities of the printer need to be enhanced and it is not feasible or possible to implement the enhancements in the MHP environment.

A printing solution that could be implemented without an advanced print server is considered better – a print server is another device that increases the cost and complexity of the system. For example, if the solution would require a PC-based print server, the computer would have to be turned on and the print server software would have to be running every time something is printed.

4.6.2 No Print Support

Architecture without any specific printing support in the MHP environment represents a minimized solution. The Xlets rely only on the standard MHP API and communicate with the print server or printer via the interaction channel.

Figure 6. No print support

In practice the approach requires an advanced print server, because otherwise Xlets would have to implement the entire printer handling logic by themselves. The same Xlet code would be broadcasted to multiple systems, so an Xlet would have to support many different kinds of printers. This would increase application development costs and code size too much.

32

In order to minimize Xlet code size, all of the printing system logic should be implemented in the print server. The Xlets would only make printing requests for the server. A common print server interface would be needed so that the Xlets accessing it could be interoperable between different home printing environments. The print server would most likely be realized in the form of a PC that would run the print server software. A system could be print-enabled by connecting the set-top-box with a PC and installing the print server software on the PC.

Xlets would communicate with the print server in TCP/IP, which is generally more difficult than interacting with an API. Basic TCP/IP could be used in simple cases where for example a printed document is streamed to the print server. A formal protocol of some kind would have to be developed for more advanced communication that would include issues like print job parameters, print job monitoring, etc. The solution applies to document and pull printing, but not for page imaging.

4.6.3 Print Support as a Library

The previous solution can be enhanced slightly with a library that the Xlets can use for printing. The classes of the library would be included in the Xlets that need to print something. Xlets would use the library through an API and the library code would handle the printing details under the hood.

The printing library itself would rely only on the standard MHP API. Similar to the previous scenario without printing support, the printing library would use the interaction channel for communicating with the print server or printer. Figure 7 visualizes the situation.

Figure 7. Print support as a library

The printing library would ease the Xlet development as they are no longer forced to implement logic for communicating in TCP/IP. It becomes more cost effective to add features

33

to the library, because the same printing library code can be reused in many Xlets. The library could hide differences in printers or print servers and implement some printing specific protocol on top of the TCP/IP. The library can support more advanced use of print job parameters and print job monitoring and can enable page imaging in addition to document and pull printing.

The solution has limitations in practice, though. Each Xlet needing print support would contain a copy of the printing library code, because the class loading scheme of the MHP does not allow them to share class files /14/. This causes pressure to keep the size of the library in minimum. On the other hand, the library would be part of the Xlets and therefore broadcasted, which means that it can not be customized. Therefore the approach would probably still rely much on the print server and offer only a small improvement on the previous architecture.

The printing library hides the interface of the print server from the Xlets, but the printing library and the print service still need to cooperate. This implies that different print servers should still share a common interface. Every Xlet does not on the other hand have to use the same library, if there are multiple different printing libraries that can all interact with the same kind of print servers.

4.6.4 Print Service Xlet

The MHP printing support could be implemented by a specialized Xlet that would offer the print service for other Xlets. Although Xlets are strictly separated from each other and are executed in different processes, MHP allows Xlets to communicate with each other via the Java Remote Method Invocation (RMI) technology /40/, which enables interaction between different processes that might be located even on different machines. In this architecture most of the printing logic would be implemented in a single print server Xlet that would provide a print API for the other Xlets. The Xlets wanting to print something would access the print server Xlet via RMI.

34

Figure 8. Print service Xlet

The solution resembles the one with a printing library. The print service Xlet could be implemented on top of the standard MHP API and again communicate with the printer or print server via the interaction channel. In principle the code size of the printing logic can be larger, because only a single copy of the code needs to be loaded into the platform.

The other Xlets using the print service survive with lesser amount of code. In order to communicate with the print server Xlet, a client Xlet needs a copy of the classes that form the public interface of the printing server. However, only interfaces of the core classes are needed in the form of stub classes, not the implementation logic, so the code size stays smaller. /40/

RMI communication is more restricted than normal interaction inside a single Java process, though. The print server Xlet must explicitly publish its services before the other applications may access it /40/. This means that the print service Xlet has to be started before its services can be accessed. It can not know in advance when some other Xlet would like to print something, so it would probably have to be running all the time. This again places restrictions on the code size and memory use of the print server Xlet.

In addition, the public print API of the print server Xlet has to be stable so that every print client Xlet may rely on it. An incompatible change in the API will render every print client unusable. In this sense the solution is more restricted than the previous one, where only a single Xlet relied on the public interface of a printing library.

4.6.5 Print Support as a Platform Service

The final scenario is based on the implementation of the printing support as a platform extension. The MHP environment would contain a printing system in addition of the regular MHP API implementation. Figure 9 demonstrates the situation.

35

Figure 9. Print support as a platform service

As a platform service the printing support would be readily usable by any Xlet. The service should have a public print API, because an API provides the most efficient way for the Xlets to interact with the service. From the Xlet point of view, the platform service would be the optimal solution.

The printing system could be configured by the properties of the current printing system i.e. the print server or printer in question. As an example, the drivers of the printer could be installed to the printing system. Printer drivers are a tricky problem for the other Xlet-based printing solutions, because Xlets are difficult to customize due to their broadcasted nature and would have to contain all the printer drivers instead of only the correct one.

The printing system could also be more closely integrated with the platform resources. As an example, a set-top-box vendor could equip the device with an additional I/O port that is used for connecting to the printer. Because the printing system implementation is not bound to the MHP API, it could use the printer port although the MHP standard supports only the interaction channel.

As a platform service the printing support resembles the printing solutions used on PCs. Therefore the solution would not necessary require a print server because PCs can typically print without such extra devices, assuming that issues such as CPU power and memory do not cause problems.

Because the classes of the print API are provided by the platform and they might not be present in every MHP system, Xlets must use caution when linking to these classes. The part of an Xlet that actually uses the print API has to be loaded separately once the presence of the print API has been confirmed. Otherwise the class loading will fail in MHP systems that do not have the printing support. The safe loading can be achieved with the Java reflection utilities, which consist mainly of the package java.lang.reflect.

36

The widespread use of the approach requires a common print API. In order to print, an Xlet has to be programmed against the API of the printing system. In theory an Xlet could support multiple different printing systems, but this is not desired as it would complicate the application development. It would be very beneficial for the Xlets if all the MHP environments with printing support would be based on the same print API.

This would mean that the vendors would have to agree on a common print API. The best way to ensure such an agreement would be to include the print API in the MHP standard itself. A standardized printing support can be thought of as the ultimate form of this scenario. It does not differ semantically from the platform extension scenario – a standardized system would definitely be a platform service.

The biggest weakness of the architecture is that it can not be implemented without effort from the MHP device vendors, who would have to actually implement the printing system. The vendors could see other features more important. Also, the embedded printing system can not be added to existing MHP implementations.

4.7 Implementation Analysis

4.7.1 Comparison of Architectures

The most important characteristics of the different architectures are summarized in the following table.

Table 5. Comparison of printing support architectures

No support Printing library Print Service Xlet

Platform Service

Document and pull printing

Yes Yes Yes Yes

Page imaging No Yes Yes Yes

Platform extensions

No No No Yes

Advanced print server

Yes Probably Probably No

37

No support Printing library Print Service Xlet

Platform Service

Critical interface TCP/IP interface of the print server

Java interface of the library and the TCP/IP interface of the print server

Java interface of the Xlet and the TCP/IP interface of the print server

The print API of the platform printing system.

All architectures except the platform service are based on the standard MHP capabilities. The biggest advantage of the solutions is that they do not require modifications to the platform and can be achieved with equipment similar to the current MHP receivers. Therefore those architectures enable the print support to be added in a short time. However, the solutions have restrictions that originate from the fact that a general printing support does not fit into the Xlet model. Xlets are broadcasted applications and a system level feature such as printing should be implemented by the platform. The problem is circumvented by relying on the print server, which becomes an important component of the overall system.

Every architecture has some critical interface – either the interface of the print server, printing library or the platform printing service. To ensure Xlet interoperability, these interfaces should be relatively fixed and mature – in an optimal situation the critical interfaces are identical in every MHP environment. This implies that existing technology should be reused in the implementation, instead of building the printing support from scratch

4.7.2 TCP/IP Printing Protocols

The Xlet-based architectures need an external printing system i.e. a print server that is accessed via the interaction channel, unless some other communication channels are available. This raises a need for a TCP/IP based printing interface or protocol that would specify how the print jobs and other information is sent over the TCP/IP connection. Various existing technologies could be applied for this:

• LPR/LPD (Line Printer Requester/Line Printer Daemon). TCP/IP based printing protocol used in Unix systems. /28/

• Internet Printing Protocol (IPP). IETF standard for Internet printing. IPP operates currently over HTTP. /29, 26/

• HP JetDirect technology is a proprietary solution that enables a form of Ethernet and TCP/IP printing. /19/

The print server would support a protocol like these. In the MHP environment the printing library or the print service Xlet would implement the client-side communication and provide an API for the actual client Xlets. The print server would receive the print requests and could for example transform them to a more low-level form required by the actual printer device.

38

The TCP/IP printing was not examined further in this study, however, because the use of a print server was considered a weakness. The platform-service architecture was preferred instead.

4.7.3 Platform Printing

The platform service architecture is based on implementing the printing system inside the MHP environment. Because the solution is not based on the Xlet model, it does not suffer from the same restrictions as the others and can therefore survive without a print server.

The platform-service architecture was selected for further study. If printing from the digital television would become common, it is likely that a solution without an additional print server would be appreciated and that some kind of printing support would be built directly to the platform. The printing support as a platform service is therefore a long-lasting solution.

The comparison of existing Java printing tools reinforced this decision. The analysis revealed a solution suitable especially for the platform-service architecture. The comparison is presented in chapter 5.

4.8 Summary This chapter analyzed various aspects relating to the MHP print support. Printing service should be accessible to any kind of Xlet. Although the actual information to be printed could not be specified beforehand, the solution should be able to generate as good prints as the printers can produce. Document and pull printing were seen valuable content delivery methods because of the potential CPU usage savings and because the print version of the content may be easier to prepare on the server-side than in the MHP environment.

The MHP receiver must support either the Interactive Broadcast or Internet Access profile for printer connections. The interaction channel should be implemented by a LAN port. If a printer would be directly connected to the MHP receiver, it should also support TCP/IP.

Several print support architectures were analyzed. The conclusions were that solutions based on the Xlet model needed most likely an external print server that would perform the duties of the printing system. A printing system implemented as a platform extension was the most promising way to achieve a printing solution that did not need extra components. The platform-service architecture was seen as a long-term solution. It was therefore selected for closer examination.

39

5 JAVA PRINTING TOOLS

5.1 History of Print Support in the Java Platform The Java platform consists of a runtime environment i.e. Java Virtual Machine (JVM) and a standard class library. Since 1998 the core platform has been referred to as the Java 2 platform, Standard Edition (J2SE), in contrast to J2EE (Enterprise Edition) and J2ME (Mobile/wireless Edition). J2SE provides generic tools for basic programming areas such as input and output, list handling and localization. The latest version of the platform is J2SE 1.5. /34/

The platform also contains a graphical user interface (GUI) toolkit called AWT (Abstract Windowing Toolkit) for desktop application and applet development. Since Java 1.1 the toolkit has also introduced a limited printing support, which has been developed further in the following platform versions. Here is a summary of the printing capabilities of the different Java platform versions: /43/

• Java 1.0: no printing support

• Java 1.1: platform printing

• J2SE 1.2: Java 2D graphics printing

• J2SE 1.3: print attributes

• J2SE 1.4: Java Print Service (JPS) API

The printing enhancements are presented in more detail in the next chapters.

5.2 Platform printing in Java 1.1 Java platform 1.1, often referred to as Java Developer’s Kit (JDK) 1.1, was released in 1997 and provided a basic printing framework for Java applications. The API relied totally on the printing facilities of the underlying operating system, which was for example Windows, Macintosh or Unix. Java applications could print on a printer that was accessible to the client platform. /43/

The API was very simple, the main class being java.awt.PrintJob that represented a single print job. Page imaging was the only way for submitting the content to the printing system. In Java, the class java.awt.Graphics defines a set of elementary rendering commands that are used for example for drawing on screen. The same class was also used in page imaging. The java.awt.PrintJob class provided applications with special java.awt.Graphics objects that were used for drawing the printed content page by page. Instead of displaying content on screen, the Graphics objects built a printable document or transformed the rendering commands to printer commands. /43/

40

The API did not provide a platform independent way for defining print attributes. Attributes were specified as simple name-value pairs, and applications needed to be aware of the print attributes used on a particular platform. /43/

MHP contains a limited set of the class library in Java 1.1.8 /14/. The subset does not include the platform printing support, however. Classes java.awt.PrintJob is not included and the method getPrintJob() in class java.awt.Toolkit, which was used for obtaining the print jobs, is removed.

5.3 Java 2D Graphics Printing The J2SE 1.2, released in 1998, introduced the java.awt.print package, which provided a print API capable of printing both AWT and Java 2D Graphics. The API was based on a callback model where the printing system controlled the printing process. Instead of the application pushing the content to the printer, it was the printer (actually the printing system) that requested the pages it wanted to be rendered. /43/

The printing capabilities were enhanced in the J2SE 1.3, which added a platform independent way for describing print attributes. Also a platform independent print dialog was introduced. Previous print APIs where relying on native print dialogs. /43/

After the inclusion of Java Print Service (JPS) API to Java Standard Edition 1.4, the Java 2D graphics printing API in package java.awt.print has been extended so that it can more easily be used together with JPS. For example, the class java.awt.print.PrinterJob has been augmented with several JPS related methods. The result is that the interface of the 2D Graphics Printing has become a kind of a hybrid of the two APIs. JPS is described in more detail in the next chapter. /33/

Page imaging was still the only method for printing. Applications had to implement interfaces java.awt.print.Pageable and java.awt.print.Printable, which modeled the content to be printed. Instances of these classes were responsible for drawing the content on the pages when requested by the printing system. /32/

Although the name of the API has the word 2D graphics in it, the use of the Java 2D Graphics API is not obligatory. None of the actual interfaces in package java.awt.print require the use of the java.awt.Graphics2D class, which is an extension of the java.awt.Graphics class and is the basis of the Java 2D Graphics API. The API could therefore be used also in MHP, which is a Java environment that does not have the 2D graphics support. /39/

5.4 Java Print Service (JPS) API

5.4.1 Overview

Java Print Service (JPS) API /39/ is an advanced and full-featured printing toolkit that is intended for both normal desktop environments and small-footprint platforms. The API was

41

developed with the code name “unified print API” /40/ through the Java Community Process /35/. The expert group contained personnel from IBM, Sun Microsystems and Xerox /40/. JPS has been part of the Java platform since version 1.4 which was released in 2002 /43/.

JPS introduces many features that were lacking from the previous printing tools. For example:

• Support for document and pull printing (in addition to the page imaging).

• Support for printing attributes specified by the Internet Printing Protocol (IPP) 1.1 /29/ standard.

• Programmatic printer discovery - applications may query for suitable printers based on the attributes of a print job.

• Support for third-party print service implementations – the set of printers that the API may use can be extended and the API is not limited to only the printers on the underlying platform.

The Java Print Service API is defined in a package of its own, in the javax.print package. Compared with previous Java platform printing toolkits, JPS is a far more complete solution and is studied with greater detail.

5.4.2 Print Services

The JPS API introduces the concept of a print service, which usually represents a physical printer. A print service is modeled by the javax.print.PrintService interface. The subclass javax.print.StreamPrintService models a special kind of print service that forwards the print data for instance into a file. Stream print services are software processes that usually perform some transformations –a stream print service implementation could for example generate a PDF file from the data and store it on the hard drive. /38/

Print services form the core of the JPS API. A JPS instance may contain several printer services, each with different capabilities. The API defines the common printing-related interfaces, but the actual capabilities of JPS as a printing system depend totally on the print services it contains.

Clients may query the printing system for printer services based on various criteria. The PrintService instances are obtained from class javax.print.PrintServiceLookup. The approach enables the clients to choose the best print service for a given print task programmatically. For example, a client may wish to select only print services that are capable of printing on both sides of the paper. /38/

The print service abstraction makes it also possible for third parties to provide custom print service implementations and install them to the printing system. The javax.print.PrintService interface can therefore be thought of as a general print driver interface for the JPS. /38/

42

Although every available print service implementation could be purely Java based, JPS takes advantage of the services of the operating system. All the printers that are available to the underlying platform are readily available in JPS as print services. So, as with the previous Java platform printing solutions, the platform printing capabilities are reused with JPS. But the javax.print.PrintService interface allows also extensions.

5.4.3 Print Service Installation

JPS does not have tools for installing new print services. Platform printers are automatically available as print services and because they are installed via the facilities of the operating system, no installation tools are created for them.

Java-based third-party print service implementations are plugged to the JPS via the Service Provider Interface of the JAR file specification /31/. Each implementation may contain a number of print services and must provide a subclass of the javax.print.PrintServiceLookup class that can be used for retrieving the print service implementations. The classes are packaged in a JAR file which must then be placed into appropriate directory under the Java application or Java platform installation. When a Java application is started, JPS discovers the JAR file and the new print service. /31, 33/

No automation tools for this are provided. The installation procedure is pretty simple, though, as it requires only that the appropriate JAR file is copied to the correct place.

5.4.4 Content Data Delivery

JPS is the only of the Java printing solutions that supports all three main content delivery methods: page imaging, document printing and pull printing. Regardless of the content delivery method, the same interface is used for the printing process. The steps for printer discovery, parameter negotiation and print job monitoring are the same. /38/

When submitting a job to the printing system, the content has to be stored in a Java object. In document printing the document is a chunk of byte or character data. The data can be made available for example as a data stream or array. Pull printing is based on URLs and on the use of class java.net.URL. /38/

Page imaging in JPS is based on the Java 2D Graphics Printing API described earlier. The interfaces java.awt.print.Pageable and java.awt.print.Printable are used in a similar fashion as in the 2D Graphics Printing API. Instances of these interfaces are responsible for rendering the printed content and are submitted to the printing system much like a document. /38/

In page imaging the content can also be presented as an instance of the class java.awt.image.renderable.RenderableImage. This is an interface for images that can be rendered optimally for various different contexts, e.g. draft preview, screen display and printer. Renderable images are more like vector images than raster images. /38, 33/

43

5.4.5 Content Data Formats

JPS uses the term doc flavor for describing the format of the data. In the API the doc flavor is visible in the form of class javax.print.DocFlavor. Instances of the class encapsulate the document format as a MIME type and also information about the type of the Java object that is used for storing the content. The MIME types are important in document and pull printing where there are multiple possible candidates and it is essential that the printing system supports the right one. /38/

The class javax.print.DocFlavor has several inner classes that define the most often used doc flavors as constants. These include several image formats such as GIF, JPEG and PNG, page description languages such as PDF, PostScript and PCL (Printer Control Language) and plain text and HTML flavors. /33/

Despite the large number of constant doc flavors the JPS does not have a standard set of supported data formats. The constants only make it easier to define the format of the printed content. The doc flavors that are actually supported depend on the capabilities of the available print services. JPS takes advantage of the printing services of the underlying platform, so the available content data formats may vary greatly. /38/

It is recommended that every print service instance would support at least the printing of plain text and java.awt.image.renderable.RenderableImage content /33/. The J2SE 1.4 release includes also a stream print service that can transform page rendering commands into PostScript. /38/

5.4.6 Print Parameters

The package javax.print.attribute defines an extensive model for describing various printing related parameters. The model is based on the concept of an attribute, which is essentially a name-value pair. The name, referred to as a category in JPS, defines the characteristic in question and the value its current value. An example of an attribute is (“Number of Copies”, 4). Attributes are used for stating the capabilities and status of a print service and the print job parameters. /38/

The interface javax.print.attribute.Attribute is the interface for all attributes. Every attribute type is expressed by a Java class that implements the interface and an instance of an attribute class holds the value of an attribute. The package javax.print.attribute.standard defines 74 basic attributes as classes. The attribute set is based on the attributes defined by the Internet Printing Protocol (IPP) 1.1 /28/. /33/

The attribute handling is therefore very advanced in JPS. The design gives applications good tools for querying the capabilities of the printers and setting print job parameters.

44

5.4.7 Printer and Print Job Monitoring

JPS provides a mechanism for monitoring both printers and print jobs. Monitoring is based on events. Clients may register as listeners for both print services (printers) and print jobs, which then notify clients about changes in the printer status or in the progress of a print job. The monitoring supported is defined in the package javax.print.event /33/. /38/

5.4.8 Print Dialog

JPS provides a cross-platform print dialog for both selecting the print service and for selecting the print request attributes. Applications may use the method javax.print.ServiceUI.printDialog for displaying a print dialog for the user. Applications may control the contents of the dialog – the available print services may be constrained and default values of the print job parameters can be preset. /33/

The print dialog of J2SE 1.4.2 running on Microsoft Windows 2000 makes it possible to choose the most common printing parameters such as number of copies , print range as pages, paper orientation and media size. Print dialog is implemented as an AWT or Swing component. A Swing component is preferred. A screenshot of the dialog is shown in Appendix 1. /38, 33/

JPS gives the print service implementations a possibility to extend the standard dialog options. Implementations may provide custom GUI components for setting device specific parameters. The framework uses the class javax.print.ServiceUIFactory for obtaining the dialog extensions. /33/

5.5 Other Java Print Tools Other suitable Java print tools besides the ones presented so far were not found. The implemented internet-based search was not extensive, but would most likely have revealed printing solutions that are in widespread use.

One Java printing solution is provided by the Eclipse project /10/. Eclipse is an open-source platform or framework for various kinds of Java development tools. The most important component is an extensible Java IDE. The platform also contains a graphical user interface toolkit of its own called Standard Widget Set (SWT). SWT has API support for printing, but because the solution is totally dependent on the SWT, which is not used in the MHP environment, this printing tool was not studied further. /10/

5.6 Suitability of JPS for MHP Environment

5.6.1 Selection Criteria

The printing support in the Java platform shows a steady evolution towards more complete and advanced printing tools. Java Print Service API is the latest outcome of the development.

45

It supports a vast array of features and has taken all the most important printing related aspects into consideration.

When compared with other Java print tools, JPS is clearly the best candidate to be used for the implementation of MHP print support. The early platform printing solution is too primitive. Java 2D Graphics Printing API was rejected because JPS contains the same page imaging support and provides in addition also document and pull printing and many other features such as standardized print attributes and print job monitoring. JPS is suitable for also small-footprint environments such as MHP – JPS is essentially only an interface and is not tied to the underlying platform. The performance requirements depend on the kind of print service implementations that are used, not on the JPS itself.

5.6.2 Platform Service Architecture

JPS, and the other presented solutions, are all platform-level APIs. As such JPS is most applicable for architecture where the MHP printing support is implemented as a platform service, although it could in theory be packaged also as a library.

5.6.3 Advantages

JPS is especially fit to serve as the MHP print API for the following reasons

Table 6. Advantages of JPS

Property Advantage

Document and pull printing support These content delivery methods are favored over page imaging in MHP due to their applicability to resource constrained environments.

Can be used both in simple printing processes and in more complex ones

A simple print service implementation may stream a document to the printer and provide only limited feedback of the process to the client.

A more advanced print service may support more content formats, perform more transformations and support printer and print job monitoring.

Driver-based printing support The PrintService interface is essentially a print driver interface. MHP needs a standard Java print driver interface if driver-based printing is to be supported.

46

Property Advantage

Print server not required Because a print service implementation may extend printer capabilities when needed, the system can be implemented without a separate print server.

API maturity JPS is the result of years of evolution. Because it is already part of the Java platform, it could be readily added to the MHP standard also.

Familiar to developers JPS is already used for printing in J2SE environment, so Java programmers developing MHP applications may already be familiar with the API.

5.6.4 Disadvantages

Table 7. Disadvantages of JPS

Property Disadvantage

Proprietary code JPS is the property of Sun Microsystems. The source code of the interfaces is viewable, but the actual implementation code is not. Permission is needed from Sun Microsystems in order to create a new JPS implementation.

Not installed separately JPS is part of the Java platform and is not distributed as an independent package. It needs to be extracted from the platform in order to be added to MHP.

5.7 Summary The printing tools provided by the standard Java platform are the only major Java based printing solutions. The printing support in Java platform has evolved in every new Java version and the Java Print Service (JPS) API represents the latest outcome of the development. JPS is an extensive print API that is the best available printing tool to be used in the MHP environment.

The platform service based architecture was identified as the most advanced scenario in chapter 4 and the JPS API is especially suitable for that scenario. It was therefore decided to

47

study the use of the API in the MHP environment further. The next chapter examines how the JPS API could be integrated into MHP and how it would be used.

48

6 PRINT SUPPORT BASED ON THE JAVA PRINT SERVICE (JPS) API

6.1 Overview This section examines how the MHP printing support could be implemented with the Java Print Service (JPS) API. The purpose is to define an augmented MHP environment that includes the JPS API. The solution requires only new classes to be added to the MHP environment; the existing MHP API is not modified. An overview of the desired arrangement is shown in Figure 10.

Figure 10. MHP environment with the JPS API

It was seen that the JPS extension concerns three separate parties:

• MHP environment providers need to know how to augment the system with the JPS API. The JPS instance in every MHP environment should be similar enough to enable interoperability for Xlet applications and print service implementations.

• Print service providers need to know how to create print service implementations for the MHP environment.

• Xlet developers need to know how to access the Java Print Service API in the MHP environments where it is available.

The intention is to give recommendations for all the parties involved. A PC-based test system was created for simulating the extended MHP environment. The test system serves as a proof of concept and solves some open issues on a detailed level.

49

6.2 Included JPS API Classes

6.2.1 Overview

The JPS API is a relatively large API. It might not always be feasible to add every possible class to the MHP. The API is therefore divided into three modules. Every MHP implementation with JPS support does not have to contain every module.

• Core JPS API Classes (mandatory)

• Page imaging support classes (optional)

• Renderable image support classes (optional)

The modules are described more thoroughly below. All the listed class names refer to classes in the Java 2 Platform, Standard Edition, version 1.4.2 /66/. In general all the classes in the same package are included for completeness. A few classes are excluded for example because they have dependencies on classes that are not available in the Java 1.1.8 platform used in MHP.

6.2.2 Core JPS API Classes

The core classes define the fundamental interfaces and classes that are needed to use the JPS API. All the classes in the core module are considered obligatory and a JPS-enabled MHP environment should therefore include them all. Table 8 lists the packages.

Table 8. Classes to be included

Package Classes

javax.print 2 of the 25 classes are excluded:

ServiceUI 1)

URIException 2)

javax.print.event All 8 classes.

javax.print.attribute All 26 classes.

Javax.print.attribute.standard 1 of the 74 classes is excluded.

Destination 2)

1) Replaced by ServiceUI of JPS4MHP API, see section 6.3. 2) Requires the java.net.URI class which is not available in MHP.

50

The packages javax.print, javax.print.event and javax.print.attribute all define important interfaces that together form the JPS API. The javax.print package contains the core printing interface, the javax.print.event provides classes for print service and print job monitoring and the javax.print.attribute defines a model for the print attributes. All the packages have dependencies to each other and all of them are therefore necessary. /33/

.The package javax.print.attribute.standard contains 74 classes that define the printing attributes that JPS understands /33/. Attributes are important because they give the print clients means to their print preferences more accurately. The number of classes is quite large, but the classes themselves are very simple and the byte size of the classes is not very big. It is hence recommended that all of the attribute classes are included, although in principle the set of the supported attributes could be adjusted.

6.2.3 Page Imaging Support Classes

Page imaging support in JPS is implemented with the Java 2D Graphics Printing API which is defined in package java.awt.print. Although page imaging is a powerful printing method, JPS supports also document and pull printing and is therefore usable even without page imaging support. The page imaging classes are therefore considered optional. Leaving those classes out makes it easier to implement the JPS instance.

The JPS API has no direct references to the classes in the java.awt.print package, so their exclusion does not cause modifications to the JPS interfaces. Table 9 lists the classes in the Java 2D Graphics Printing API.

Table 9. Classes for Page Imaging Support

java.awt.print

(2 classes) Interfaces: Pageable Printable PrinterGraphics

Classes:

Book (not directly required) PageFormat (required by Pageable and Printable)Paper (required by PageFormat) PrinterJob (required by PrinterGraphics)

Exceptions: PrinterAbortException PrinterException PrinterIOException

Note that although a JPS instance contains the page imaging support classes, it might not contain a print service that would actually support page imaging.

51

6.2.4 Renderable Image Support Classes

The interface java.awt.image.renderable.RenderableImage can also be used in page imaging. It is even recommended that every print service implementation should support printing of renderable images /33/.

The class RenderableImage causes problems, however. It has dependencies to the class java.awt.image.renderable.RenderContext, which again has dependencies to various 2D graphics classes in packages java.awt and java.awt.geom. Therefore the addition of the RenderableImage class would require the addition of almost the whole 2D graphics API, which requires too much effort. The interface java.awt.image.renderable.RenderableImage and its associated classes are therefore considered optional. In addition, a print service built for the MHP environment does not have to support renderable images.

6.3 MHP Specific Extensions to JPS

6.3.1 Overview

The JPS API needs some extensions and modifications in order to be fully functional in the MHP environment:

1. Print service installation: The manual print service installation is not well suited for MHP.

2. Printer connections: JPS does not specify how the print service implementations find out the location of the printers and communicate with them.

3. Print dialog: a HAVi-based print dialog must be provided for the Xlet applications.

The items 2 and 3 needed Java interfaces in order to be solved. These extensions were implemented in a software module named JPS4MHP, which was created as part of the test system. JPS4MHP consists of only a few classes that are defined in package fi.hut.media.jps4mhp.framework. The package is part of the printing system and should be implemented by the MHP receiver vendor together with the JPS API.

6.3.2 Print Service Installation

A JPS instance should provide a method for installing print services. The installation requires that the JAR file of the print service implementation is downloaded from the broadcast stream or via the interaction channel and it is copied to a correct place in the system. The installation may also include configuration of the print services. For example, the printer connections discussed in the next section could be configured as part of the installation process. The platform should most likely provide a GUI for the end user for these tasks.

The print service installation and configuration tool can be platform specific, however. Therefore no standard solution needs to be provided for this. But every JPS instance should

52

provide some support for installing print services. A platform could have a fixed set of built-in print services, but the inability to support new print services would nullify much of the flexibility of the JPS API.

6.3.3 Printer Connections

JPS does not define how the print service implementations communicate with the printers. In most cases this does not matter because JPS relies on the print support of the underlying platform. Only fully Java based print services need to solve the issue by themselves.

Unless the MHP platform provides some built-in print services, the print services in the MHP environment are totally Java based implementations. As mentioned before, they would most likely use the interaction channel for communicating with the printers. In that case the print services would need to know at least the TCP/IP address of the printer in order to send data to it.

The TCP/IP address of the printer is specific to the particular MHP system. The end user could for example set the address during printer installation. A print service should get the information from the platform. Print service implementations should be compatible between MHP systems, so the print services need a standard method for establishing a connection to a printer.

The class fi.hut.media.jps4mhp.framework.PrinterConnectionManager defines a Java interface that the print services may use for accessing printers (Appendix 2). The class provides the following method to be used for this:

java.net.Socket getPrinterConnectionFor(PrintService printService)

The method is essentially a mapping from a javax.print.PrintService instance to a java.net.Socket object. The java.net.Socket class is used by the Java platform in communicating between two machines via for example a TCP connection /33/. Print service implementations may use the Socket instance in bidirectional communication with the printer. The interaction channel would most likely be exploited in the actual data transfer.

In the design the print services do not know the location of the printer; it is the responsibility of the platform to map print services to printers. The mapping could be created as part of the print service installation. The approach makes it possible to use multiple print services with multiple printers. Each print service may use a different printer or be connected to the same device. In addition, the platform could use any suitable I/O channel for the printer connections – the interaction channel or a platform-specific extension. This detail is hidden from the print services. A change in the communication channels does not affect them.

The JPS4MHP API contains the class SimplePrinterConnectionManager, which is a simple implementation of the PrinterConnectionManager intended for testing purposes.

53

The implementation stores the configuration details into Java Properties files that are saved into the file system. In a real MHP environment the platform would provide a custom implementation of the PrinterConnectionManager class.

6.3.4 Print Dialog

Applications obtain the print dialog from the JPS via the class javax.print.ServiceUI (Appendix 2). The class has the following static method:

static PrintService printDialog( GraphicsConfiguration gc, int x, int y, PrintService[] printServices, PrintService defaultService, DocFlavor flavor, PrintRequestAttributeSet attributes)

The method displays a print dialog for the end user on the screen defined by the java.awt.GraphicsConfiguration instance at the given location. The other arguments affect the options shown in the dialog.

The graphics environment of the MHP does not support a windowing system, so a window-based dialog used in a PC environment can not be used. Instead, the print dialog should be based on the HAVi model.

JPS4MHP API provides the class fi.hut.media.jps4mhp.framework.ServiceUI for this. The class has a static method very similar to the one in class javax.print.ServiceUI: static PrintService printDialog( org.havi.ui.HScene scene, PrintService[] printServices, PrintService defaultService, DocFlavor flavor, PrintRequestAttributeSet attributes)

The java.awt.GraphicsConfiguration instance and the coordinates are replaced by the org.havi.ui.HScene instance. The HScene class forms the foundation of the HAVi user interface toolkit and serves as a top-level component, similar to a window in AWT. HScene allows components to overlap each other. Therefore the print dialog could be implemented by placing it on top of the HScene of the Xlet application.

The method in class fi.hut.media.jps4mhp.framework.ServiceUI makes sure that the platform gets a reference to the correct HScene where the print dialog must be displayed.

A primitive implementation of the actual print dialog was created and can be found in package fi.hut.media.jps4mhp.framework.ui. The implementation serves as an example and

54

is not to be used in a real-life situation. A solid implementation would have required a lot of GUI programming which was not considered to be in the focus of this study.

The contents of the print dialog are not critical once the applications have a standard interface for displaying the dialog. A more advanced dialog implementation can be created in the future. Before that, each platform may provide its own print dialog.

6.4 JPS Support Discovery MHP uses system properties for signaling about which of the optional features of the MHP are supported by a platform /15/. It is hence recommended that the availability of the JPS API is stated with the same method. Table 10 lists the new system properties.

MHP uses the syntax mhp.option.<optional feature name> in the system property names /15/. However, the prefix mhp.option should be reserved only for features that are part of the MHP standard. Therefore the prefix javax.print, the package name of the JPS API, is used in the property names instead.

If the JPS API is some day added to the MHP as an optional feature, the property name inside the braces could be used.

Table 10. System properties for JPS support discovery

System property name Description

javax.print

(mhp.option.jps) Signals the presence of the core JPS classes as listed in section 6.2.2 and the JPS4MHP classes defined in section 6.3.

javax.print.pageimaging

(mhp.option.jps.pageimaging) Signals the presence of the page imaging support classes listed in section 6.2.3.

javax.print.renderableimage

(mhp.option.jps.renderableimage) Signals the presence of the java.awt.renderable.RenderableImage and the associated classes as described in section 6.2.4.

6.5 Test System

6.5.1 Overview

The desired environment was simulated with a test system shown in Figure 11.

55

Figure 11. Test system

The test system consists of the following components:

• OpenMHP: an open-source MHP emulator provided the MHP environment /46/

• JPS API of the J2SE 1.4.2

• JPS4MHP API: provides a few MHP specific extensions to JPS.

• SimplePrint: A trivial print service implementation

• XletClient: A simple Xlet application that uses the JPS API for printing.

The underlying operating system was Microsoft Windows 2000 Professional. The computer was connected to a Color LaserJet 5550 dtn /18/ printer via LAN connection.

6.5.2 OpenMHP

The environment was based on OpenMHP /46/, which is a Finnish open-source MHP emulator. OpenMHP is a completely Java-based implementation of the MHP API that runs as a normal Java application in a PC environment. OpenMHP makes it possible to test Xlet applications without an actual MHP receiver device. /46/

The test system used OpenMHP 1.0.3. The version is only a partial implementation of the MHP API and the OpenMHP project does not specify what MHP version or profile the software is based on /46/. Regardless of the limitations, the emulator was sufficient for the purposes of the test system and most importantly OpenMHP could be executed in J2SE 1.4.2 /33/, which contained the JPS API.

56

6.5.3 Java Print Service (JPS) Instance

OpenMHP does not prohibit the use of non-MHP APIs in any way. Because J2SE 1.4.2 was used instead of Java 1.1.8, the Java platform version used by the MHP, a full implementation of the JPS API was readily accessible to the Xlet applications.

6.5.4 JPS4MHP API

JPS4MHP API provides a few MHP specific extensions to MHP that were already described in chapter 6.2. The classes of JPS4MHP API were packaged in a JAR file and added to the classpath of the OpenMHP. This way the API became part of the platform and was accessible to every Xlet running in OpenMHP.

The classes in the JPS4MHP API are listed in more detail in Appendix 2.

6.5.5 SimplePrint

SimplePrint is an implementation of a print service. It is a simple service that is capable of streaming PDF documents to a printer. SimplePrint does not perform any transformations – it assumes that the printer supports direct printing of PDF documents. The test environment was connected to HP Color LaserJet 5550 dtn /18/ printer. The printer is a work-group printer and does not represent a common model used in home-printing, but was used because it could be accessed via LAN connection and it supported direct printing of PDF files, which made the implementation of SimplePrint easy.

SimplePrint is defined in package fi.hut.media.jps4mhp.simpleprint (see Appendix 3). The classes are listed in Table 11.

Table 11. SimplePrint classes

Class Description

PrintServiceLookup Implementation of the javax.print.PrintServiceLookup that the JPS uses for obtaining SimplePrintService instances.

SimplePrintService This class mainly defines the attributes and document types supported by the service.

SimplePrintServiceJob Implementation of the javax.print.PrintJob class that actually pushes the PDF document to the printer.

The classes were packaged into a JAR file together with information that made it possible to install the SimplePrint to the JPS via the Service Provider Interface (SPI) /31/. The JAR file was added to the classpath of OpenMHP. The JPS instance of J2SE 1.4 discovered the

57

implementation automatically and the SimplePrint appeared as one of the print services in the JPS under the name “Direct PDF Printer”.

SimplePrint uses the class PrinterConnectionManager in the fi.hut.media.jps4mhp.framework package for connecting to a printer. The TCP address of the printer was configured to the Java properties files read by the SimplePrinterConnectionManager. This way the SimplePrint JAR file was totally platform independent and would be usable in every JSP-enabled MHP system that would be connected to an appropriate printer.

6.5.6 XletClient

XletClient is a simple Xlet application that demonstrates the use of the JPS API. The application can print a PDF file with the JPS API. In this case the PDF files are bundled with the Xlet, but they could also be downloaded from a server when needed. The printing process is started by the user. XletClient displays a screen that shows some meta-data of the PDF file and gives the user the option to print it. A screenshot of the XletClient executing in OpenMHP is shown in Figure 12.

Figure 12. XletClient screenshot

Note that the screen is built only for testing purposes and is not meant to be an example of an Xlet GUI. In a real-life situation the screen could for example display parts of the actual content instead of meta-data. But regardless of the GUI, the application would give some option to the user for starting the process.

58

When user presses the red button, the following things occur:

1. The application queries for a set of PrintService instances from the JPS instance by calling method lookupPrintServices in class javax.print.PrintServiceLookup.

2. In the test environment the PrintServiceLookup returns 3 print services: 2 printers that originate from the Windows platform and the SimplePrint print service (under the name “Direct PDF Printer”.)

3. The application lets the user choose print options and displays a print dialog by using the method printDialog in class fi.hut.media.jps4mhp.framework.ServiceUI.

4. The ServiceUI class creates the trivial print dialog implementation and places it on top of the HScene of the application. A screenshot of the situation is shown in Figure 13.

5. The user selects a print service with the arrow keys and the red button.

6. The ServiceUI hides the dialog and returns the user-selected PrintService instance to the application.

7. The application prints the PDF file with the print service. No feedback is currently given to the user so the application returns to the same screen as before the printing process.

The example shows the most important characteristics of JPS based printing. The current print dialog allows the user only to choose a printer, but in real-life situations the selection of the print parameters would probably be more important, because there are not usually many printers available in home printing.

59

Figure 13. Simple print dialog of the JPS4MHP API

The XletClient application is defined in package fi.hut.media.jps4mhp.xletclient. See Appendix 3.

6.5.7 JPS Support Discovery

The JPS support discovery methods presented in section 6.4 were not implemented in the test system because it was considered trivial. The implementation would have required the addition of a few system properties to the Java environment and a small modification to the XletClient.

6.6 Summary This section described how the JPS API would be integrated into the MHP environment. The integration must be done by the MHP environment provider like a set-top-box vendor for example, and includes the following tasks:

• The implementation of the parts of the JPS API as defined in section 6.2.

• The implementation of the JPS extensions i.e. the JPS4MHP API as defined in section 6.3

• Addition of a few system properties for JPS support discovery as defined in section 6.4.

60

The system must also implement either the Interactive Broadcast or the Internet Access profile. Some kind of a persistent storage is required for storing the print service installations.

Print service implementations are created and packaged for MHP much like they are created for regular Java systems. The biggest differences are that the MHP API is available instead of the full J2SE 1.4 platform and that the implementations may use the JPS4MHP API for connecting to the printers.

Xlets may discover the JPS support with the methods given in section 6.4. The JPS API is used like in other environments except that Xlets must be aware of the modules present in the system. Also, Xlets use the JPS4MHP API for displaying the print dialog.

61

7 CONCLUSIONS

7.1 External Print Server vs. Platform service A complete print support requires a printing system that provides print clients with a higher-level interface and hides the differences and low-level details of printer devices. The MHP print support is therefore realized with a printing system that must be accessible to Xlet applications, the print clients in the MHP environment. Two different approaches can be used in the implementation of the printing system:

1. The printing system is implemented outside the MHP receiver, in an external print server.

2. The printing system is implemented in the MHP receiver, as an extension to the MHP platform.

The first alternative does not require changes to the MHP environment, which is its biggest advantage. The external print server might be actualized by printing service software running on a PC. In the second alternative the printing system is implemented as a platform-level service. It requires an extension to the MHP environment, but enables printing without additional components.

Neither approach could be clearly rejected. The possibility to cope without an external print server was valued and the platform-level printing support was chosen for closer study. The other approach was considered a short-term solution and although feasible, was not covered further.

7.2 Print Support Based on the Java Print Service API The Java Print Service (JPS) API is clearly the best alternative of the reviewed Java-based printing tools and would provide an advanced and extensive printing interface for the Xlet applications. The platform-level print support should therefore be implemented with the JPS API; an MHP environment provider, e.g. a set-top-box vendor, should add the JPS API on the side of the standard MHP API as a platform-specific extension.

The JPS API implements the most important aspects related to printing – multiple content delivery methods, a model for print parameter negotiation, printer and print job monitoring, etc. The system is not tied to any particular kind of printer; the PrintService interface can be used as a printer driver interface, which enables the printing system to communicate with many different printers.

The JPS API needed a few extensions in order to be fully usable. The additional parts are provided in the JPS4MHP API, which was created as part of this study. The extension module is very small and contains only two important classes. The overall solution is therefore quite consistent.

62

7.3 Future Directions Although first implemented as a platform-specific extension, the JPS API could later be included into the MHP standard itself. This prospective encourages the utilization of JPS; the API is already the standard printing API of the normal Java platform and is hence a good candidate to be the standard printing API of the MHP also.

On a greater scale the use of JPS could be seen as part of the convergence of the standard Java platform and MHP. The MHP API consists of a cut-down version of the Java 1.1.8 and a number of MHP specific APIs. Resource requirements are the biggest reason for not including a complete J2SE platform. If the computing capacity of the MHP receivers increases, however, the two platforms could become closer to each other. The Java platform in the MHP environment could perhaps be enhanced with various new APIs from the latest standard Java platform.

The larger convergence process may even be a prerequisite for the utilization of JPS. Although a receiver manufacturer could decide to simply implement JPS in a way described in this document, such a platform extension might not be seen as valuable on its own. The JPS API enables only printing and it is unknown whether the digital television industry sees some other new feature as more important.

On the other hand, some MHP receivers could be based more on the PC technology than the normal small-footprint devices and could decide to include the full J2SE 1.4 platform. Whether this will happen depends on the evolution of digital television – will it remain primarily a receiver of the digital TV image or will the interactive aspects flourish and bring the set-top-boxes closer to general purpose computers.

63

8 SUMMARY In order to make widespread home printing from the digital television possible, the MHP environment has to be equipped with print support. The print support would be realized in the form of a printing system, a software based module whose responsibility is to make printing more straightforward for the MHP applications. A printing system can abstract differences of printer devices away and provide a higher level printing interface to the print clients.

However, MHP systems are restricted and optimized for executing broadcasted applications. The privileges and responsibilities of the MHP applications are well-defined and controlled. This impeded the implementation of the printing system in the context of MHP. Several implementation scenarios were analyzed and it was concluded that a complete print support could be built on top of standard MHP only if an advanced printer server would be available. Another option was to implement the printing system in the platform as an extension to the standard MHP.

The use of an external print server was considered undesirable. The implementation of the printing support as a platform extension was seen as the only option which would be functional without additional components and which represents a long-term solution. It was therefore decided to study the platform service scenario further.

The analysis of existing Java printing tools revealed that the platform-level printing support would be best implemented with the Java Print Service (JPS) API which is the standard printing solution of the current Java platform. JPS would provide an advanced and extensible printing support. In the first phase it would be implemented by an MHP receiver vendor as a platform-specific extension. If proven popular the API is well-fitted to be included into the MHP standard also.

The implementation of the JPS API in the MHP environment was defined in more detail in the last section. MHP environment providers were given recommendations on how to implement the API. Guidelines were also given for print service providers and Xlet application developers. The JPS API needed a few extensions in order to be fully usable in the MHP environment. The required interfaces were defined in a small software module named JPS4MHP API.

A test system was created for demonstrating the solution. The test system employed an MHP emulator that allowed the MHP environment to be extended with the JPS API. The system included in addition an implementation of the JPS4MHP API, an example of a purely Java-based print service and an application that showed how the JPS API would be accessed by an Xlet. The application was capable of printing a PDF document with the JPS API in the test environment.

64

REFERENCES 1. Adobe Systems Incorporated. Adobe PDF. (online), [Accessed 27.2.2005].

<http://www.adobe.com/products/acrobat/adobepdf.html>

2. Adobe Systems Incorporated. Adobe Postscript 3. (online), [Accessed 15.11.2004]. <http://www.adobe.com/products/postscript/main.html>

3. Apple Computer Inc. Introduction to the Mac OS X Printing System. 2002 (online), updated 11.12.2002, [Accessed 3.12.2004]. <http://developer.apple.com/documentation/Printing/Conceptual/About_MacOSX_Printing/index.html>

4. Axis Communications. Mobile Printing – Today and in the Future Whitepaper. 2001 (online), updated 5.2.2001, [Accessed 12.1.2005]. <http://www.axis.com/documentation/whitepaper/5800/wp_5800.pdf>

5. Berkema, Alan. Minimal Basic Printing Profile Requirements for a Sender, White Paper, Revision 1.0. Bluetooth SIG, 2002.

6. Bluetooth SIG. Bluetooth.org – The Official Bluetooth Membership Site. (online), [Accessed 23.11.2004]. <http://www.bluetooth.org/>

7. CIPA DC-001–2003. Digital Photo Solutions for Imaging Devices. Standard of Camera & Imaging Products Association, 2003 (online). [Accessed 8.3.2005]. <http://www.cipa.jp/pictbridge/>

8. Daniels, Anthony. The new DVB MHP spec and its implications for networked multimedia into the home. Appliance-Lab LLC, 2002 (online), updated 18.9.2002, [Accessed 22.11.2004]. <http://www.iapplianceweb.com/story/oeg20020918s0040.htm>

9. Digital Video Broadcasting Group. DVB Home. (online), [Accessed 1.11.2004]. <http://www.dvb.org>

10. Digital Video Broadcasting Group. Multimedia Home Platform (MHP) Home. (online), [Accessed 1.11.2004]. <http://www.mhp.org>

11. Eclipse Foundation. Eclipse.org. Main Page. (online), [Accessed 15.11.2004]. <http://www.eclipse.org/>

12. Edwards, Newman, Sedivy, Smith. Supporting serendipitous integration in mobile computing environments. International Journal of Human-Computer Studies Volume 60, Issues 5-6. (May 2004). Pp. 666-700.

13. Epson (UK) LTD. Mustesuihkutulostimet. (online), updated 11.8.2004, [Accessed 8.3.2005]. <http://www.epson.fi/products/ink.htm>

65

14. ETSI TS 101 812 v1.3.1. Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3. European Telecommunications Standards Institute, 2002. 787 p.

15. ETSI TS 102 812 v1.2.1. Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1. European Telecommunications Standards Institute, 2003. 1086 p.

16. Hewlett-Packard Development Company, L.P. External Print Servers. (online), [Accessed 16.2.2005]. <http://h10010.www1.hp.com/wwpc/us/en/sm/WF02a/18972-236253-64302.html>

17. Hewlett-Packard Development Company, L.P. Home Printers. (online), [Accessed 8.3.2005]. <http://h50025.www5.hp.com/hpcom/nz_en/10_35.html>

18. Hewlett-Packard Development Company, L.P. HP Color LaserJet 5550dtn Printer (Q3716A) - specifications and warranty. (online), [Accessed 24.2.2005]. <http://h10010.www1.hp.com/wwpc/us/en/sm/WF06b/18972-236251-236268-15077-f58-409994-406811-406812.html>

19. Hewlett-Packard Development Company, L.P. Internal Print Servers. (online), [Accessed 16.2.2005]. <http://h10010.www1.hp.com/wwpc/us/en/sm/WF02a/18972-236253-236264.html>

20. Hewlett-Packard Development Company, L.P. Wireless Network Print Servers. (online), [Accessed 16.2.2005]. <http://h10010.www1.hp.com/wwpc/us/en/sm/WF02a/18972-236253-396578.html>

21. Lexmark International, Inc. Home Printing. (online), [Accessed 8.3.2005]. <http://www.lexmark.com/uncomplicate/sequentialem/home/0,7070,204816596_237452712_0_en,00.html>

22. Microsoft Corporation. Windows GDI: Printing and Print Spooler. MSDN Library (online), [Accessed 3.12.2004]. <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_62ia.asp>

23. Microsoft Corporation. Windows Server System: Printing and print servers. (online), [Accessed 16.2.2005]. <http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_PRINTconcepts_ps_queue_spooler.asp>

24. Morris, Steven. The MHP Tutorial. 2004 (online), [Accessed 12.11.2004]. <http://www.mhp-interactive.org/tutorial/mhp/index.shtml>

66

25. Newell, J.C. An Introduction to MHP 1.0 and MHP 1.1. BBC, Research & Development, 2002 (online), [Accessed 17.1.2005]. <http://www.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP030.pdf>

26. Printer Working Group. Internet Printing Protocol. 2000 (online), updated 07.08.2003, [Accessed 15.11.2004]. <http://www.pwg.org/ipp/>

27. Printing Working Group. Basic Printing Profile – Interoperability Specification. 2001 (online), [Accessed 25.11.2004]. <http://www.proteam.com.cn/bluetooth/documents/profile/PP_095a.pdf>

28. RFC 1179. Line Printer Daemon Protocol. The Wollongong Group, 1990. 14 p (online), [Accessed 16.2.2005]. <http://www.ietf.org/rfc/rfc1179.txt>

29. RFC 2911. Internet Printing Protocol/1.1: Model and Semantics. IETF Network Working Group, 2000. 224 p (online), [Accessed 16.2.2005]. <http://www.ietf.org/rfc/rfc2911.txt>

30. Smith-Chaigneau, Anthony. DVB-MHP – A Snapshot. Sandberg Media, 2001 (online), updated 4.11.2001, [Accessed 22.11.2004]. <http://www.broadcastpapers.com/data/DVBMHPSnapshot%20-%20print.htm>

31. Sun Microsystems. JAR File Specification. 1999 (online), [Accessed 10.12.2004]. <http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html>

32. Sun Microsystems. Java 2 Platform SE 1.3.1 API. (online), [Accessed 7.2.2005]. <http://java.sun.com/j2se/1.3/docs/api/>

33. Sun Microsystems. Java 2 Platform SE 1.4.2 API. 2003 (online), [Accessed 3.11.2004]. <http://java.sun.com/j2se/1.4.2/docs/api/index.html>

34. Sun Microsystems. Java 2 Platform, Standard Edition. (online), [Accessed 3.2.2005]. <http://java.sun.com/j2se/index.jsp>

35. Sun Microsystems. Java Community Process Home. (online), [Accessed 10.12.2004]. <http://jcp.org/en/home/index>

36. Sun Microsystems. Java Media Framework (JMF) API. (online), [Accessed 12.11.2004]. <http://java.sun.com/products/java-media/jmf/index.jsp>

37. Sun Microsystems. Java Platform 1.1.8 API Specification. (online), [Accessed 11.12.2004]. <http://java.sun.com/products/archive/index.html>

38. Sun Microsystems. Java Print Service API User Guide. 2001 (online), [Accessed 4.11.2004]. <http://java.sun.com/j2se/1.4.2/docs/guide/jps/spec/jpsTitle.fm.html>

39. Sun Microsystems. Java Print Service. (online), [Accessed 15.11.2004]. <http://java.sun.com/j2se/1.4.2/docs/guide/jps/>

67

40. Sun Microsystems. Java Remote Method Invocation (Java RMI). (online), [Accessed 8.3.2005]. <http://java.sun.com/products/jdk/rmi/>

41. Sun Microsystems. Java TV API. (online), [Accessed 10.3.2005]. <http://java.sun.com/products/javatv/>

42. Sun Microsystems. JSR 6: Unified Printing API (Java Print Service API). 1999 (online), [Accessed 4.11.2004]. <URL: http://jcp.org/en/jsr/detail?id=006>

43. Sun Microsystems. Printing Help for Java Developers. (online), updated 8.10.2004, [Accessed 15.11.2004]. <http://java.sun.com/printing/whitepaper.html>

44. Sun Microsystems. Printing on the Java Platform. 2000 (online), updated 4.8.2000, [Accessed 4.11.2004]. <URL: http://java.sun.com/printing/>

45. TechTarget. Printer Control Language. (online), updated 30.12.2002, [Accessed 24.11.2004]. <http://searchsmallbizit.techtarget.com/sDefinition/0,,sid44_gci214283,00.html>

46. Tucs and Axel Technologies. OpenMHP – OpenMHP is a Free implementation of MHP classes. (online), [Accessed 21.2.2005]. <http://www.openmhp.org/>

47. Vogt, C. The DVB MHP Specification – A Guided Tour. World Broadcast Engineering – Spring Edition 8 p (online), [Accessed 17.1.2005]. <http://www.alticast.co.kr/downloads/MHP%20Guide.pdf>

48. Webopedia. Page description language definition. (online), [Accessed 15.11.2004]. <http://sbc.webopedia.com/TERM/P/Page_Description_Language_PDL.html>

49. Webopedia. Printer driver definition. (online), [Accessed 15.11.2004]. <http://sbc.webopedia.com/TERM/P/printer_driver.html>

50. Webopedia. What is pull printing? (online), [Accessed 24.11.2004]. <http://www.webopedia.com/TERM/P/pull_printing.html>

51. Webopedia. What is spooling?. (online), [Accessed 15.11.2004]. <http://www.webopedia.com/TERM/s/spooling.html>

52. World Wide Web Consortium. W3C Html Page. (online), updated 22.07.2004, [Accessed 15.11.2004]. <http://www.w3.org/MarkUp/>

53. XHTML-Print, W3C Candidate Recommendation. World Wide Web Consortium, 2004 (online), updated 18.9.2004, [Accessed 23.11.2004]. <http://www.w3.org/TR/xhtml-print/>

68

APPENDIX 1: JPS PRINT DIALOG

Figure 14. Standard JPS Print Dialog in J2SE 1.4.2 running on Windows 2000

69

APPENDIX 2: JPS4MHP API This section lists the API specification of the two public classes in package fi.hut.media.jps4mhp.framework.

The source code and JavaDoc comments can be found at:

http://www.hut.fi/~ttlaitin/jps4mhp/

Class PrinterConnectionManager

public abstract class PrinterConnectionManager extends Object

PrinterConnectionManager is used by PrintService-implementations for communicating with printers. It is needed because PrintServices can not know how the available printers are connected to a given MHP system.

PrinterConnectionManager abstracts the communication channel used for communicating with printers. It provides the PrintServices with a Socket instance that they can use for bidirectional communications.

The interaction channel of the MHP instance is most likely used as the communication channel. A MHP receiver could provide also alternative channels.

Different PrintService-instances may be configured to use different printers. The idea is that the platform provides some method for mapping the PrintService-implementations to a particular printer. For example, the MHP system could provide a GUI that the end user uses for configuring the connections at the same time when a new PrintService-implementation is installed to the system.

Author:

Timo Laitinen

Method Detail

public static PrinterConnectionManager getInstance()

Description:

Returns the platform-provided PrinterConnectionManager instance.

Returns:

PrinterConnectionManager

70 public abstract Socket getPrinterConnectionFor(PrintService printService) throws IOException, IllegalStateException

Description:

Called by PrintService implementations for accessing a printer.

Parameters:

printService - the PrintService instance that wants to use a printer. The PrintService is identified both by its class name and name (obtained by PrintService.getName()). The name of a PrintService should therefore not change between invocations. Also, the names of the PrintServices should be unique within instances of the same class.

Returns:

Socket that the PrintService may use for communicating with the printer.

Throws:

IOException - if the connection could not be established due to I/O problems. IllegalStateException - if the connection could not be established because due to platform problems. For example, the printer connections of the platform might not be configured or the connection for the given PrintService could not be found.

Class ServiceUI

public class ServiceUI extends Object

Author:

Timo Laitinen

Method Detail

public static PrintService printDialog(org.havi.ui.HScene scene, PrintService[] services, PrintService defaultService, DocFlavor flavor, PrintRequestAttributeSet attributes) throws HeadlessException, org.havi.ui.HUIException

Description:

Displays a standard print dialog for the user. The dialog is a HAVi-based dialog provided by the JPS instance. This method can be called by Xlet applications that want to find out the print preferences of the user.

71

The method mimics the method javax.print.ServiceUI.printDialog. This method is designed for HAVi environment, where a window-based dialog can not be used. The HAVi-dialog can implementated by for example placing the dialog-component in front of the current top-most component in a HScene.

Note: this method should never be called from the AWT event thread. The method will block until the user has closed the dialog.

Parameters:

scene - the HScene where the dialog is displayed.

services - the available print services that the user can choose from.

defaultService - preselected print service. must be one of the available print services. if null, the first print service from the list is selected.

flavor - DocFlavor the flavor to be printed.

attributes - PrintRequestAttributeSet the set of print parameters. The attribute values are modified according to the selections of the user.

Returns:

The PrintService instance selected by the user. If the user canceled the print, null is returned.

Throws:

HeadlessException

org.havi.ui.HUIException

72

APPENDIX 3: SIMPLEPRINT AND XLETCLIENT The source code and JavaDoc comments of the SimplePrint and XletClient can be found at:

http://www.hut.fi/~ttlaitin/jps4mhp/