Search   |   Back Issues   |   Author Index   |   Title Index   |   Contents



D-Lib Magazine
September/October 2008

Volume 14 Number 9/10

ISSN 1082-9873

Introducing djatoka

A Reuse Friendly, Open Source JPEG 2000 Image Server


Ryan Chute
Los Alamos National Laboratory, Research Library

Herbert Van de Sompel
Los Alamos National Laboratory, Research Library

Red Line



The ISO-standardized JPEG 2000 image format has started to attract significant attention. Support for the format is emerging in major consumer applications, and the cultural heritage community seriously considers it a viable format for digital preservation. So far, only commercial image servers with JPEG 2000 support have been available. They come with significant license fees and typically provide the customers with limited extensibility capabilities. Here, we introduce djatoka, an open source JPEG 2000 image server with an attractive basic feature set, and extensibility under control of the community of implementers. We describe djatoka, and point at demonstrations that feature digitized images of marvelous historical manuscripts from the collections of the British Library and the University of Ghent. We also call upon the community to engage in further development of djatoka.

1. Introduction

The Digital Library Research & Prototyping Team at the Los Alamos National Laboratory (LANL) enjoys tackling challenging problems. And so we read Hiding Magna Carta on the Web [1] on the eFoundations blog with interest. In the blog entry, Andy Powell expresses his frustration about the way the British Library (BL) made the digitized version of the Magna Carta [2] available online. The BL used a Shockwave applet, as such "... making it pretty much impossible to do anything other than browse it on the BL's Web site". After sharing some more observations, Andy concludes, "... re-use wasn't high on the BL's agenda". To be fair, the BL is far from being the only cultural heritage institution to use the applet approach, and the same practice is also common beyond the cultural heritage sector where it is frequently used for the display of astronomical images, satellite images, medical imagery, etc. Sometimes, protection of intellectual property is the motivation for the approach, but we wondered what led institutions down a technical path that prevents creative, Web 2.0 style reuse, when no such concerns are involved. Could it be that appropriate tools were missing?

Around the same time, we anticipated a concrete need to introduce a solution to disseminate high-resolution images stored in our aDORe repository [3,4]. We set out to explore the problem domain and ended up developing the aDORe djatoka dynamic image dissemination solution, an open source package with an attractive feature set capable of disseminating images that reside either in a djatoka environment or that are Web-accessible at arbitrary URIs.

2. Disseminating High Resolution Images on the Web

There are hardly any challenges involved in disseminating sizeable images on the Web. Just save the image in a well-supported format on your Web server, give it a URI, and you're done. But, when the image size reaches the realm of hundreds of megabytes or gigabytes, as is the case with many high-resolution images that result from digitization, dissemination becomes far less trivial. One part of a common solution to the problem is to create a derivative image in a selected service format. This is typically a multi-resolution image file format (e.g., MrSID, JPEG 2000, Pyramid TIFF) that encapsulates a set of resolutions and is derived from the master image, which in many cases is a TIFF file that itself is never used for dissemination. As a benefit, these multi-resolution image formats typically support dynamic region extraction. Another part of the solution is to stream equally sized chunks of the derivative image to a Web client instead of delivering it in its entirety. We have all become familiar with this tiling approach through Google Maps. The tiling approach commonly requires the pre-generation and storage of each tile at all levels of resolution, which significantly increases storage requirements [5]. At the client end, typical solutions use a JavaScript-driven HTML viewer (see [note 1] for the Magna Carta) or a viewer based on a browser plug-in such as Flash (see [note 2] for the Magna Carta). Typically, these viewers minimally allow paging (navigation across image sections) and zooming.

There are many image dissemination platforms available, including Lizardtech's GeoExpress, Luna Imaging's Media Manager, the eRez Imaging Server, and Zoomify. An evaluation of their functionality is beyond the scope of this article, but we do want to note the following characteristics, not necessarily shared by all platforms, that we perceived as problematic:

  • Proprietary, patented nature of the service format (cf. MrSID);
  • Steep license fees for software;
  • Lack of open source implementations;
  • Lack of an easily extensible dissemination service framework (e.g., identifier schemes imposed by vendor as opposed to openness to a variety of identifier schemes, watermarking, etc.).

3. Introducing djatoka

We decided to try and address these issues and engaged in the development of the aDORe djatoka (with silent "d") dynamic image server. These are djatoka's representative characteristics:

  • Use of the ISO-standardized JPEG 2000 format [6] as the service format;
  • Java-based open source solution built around the Kakudu JPEG 2000 library;
  • Geared towards reuse through URI-addressability of all image disseminations including regions, rotations, and format transformations;
  • Provision of a consistent, guessable URI pattern for image disseminations based on the ANSI/NISO OpenURL standard [7];
  • Provision of an extensible service framework for image disseminations enabled by OCLC's Java OpenURL package;
  • Availability of image disseminations in a range of image formats;
  • Availability of image disseminations for locally stored JPEG 2000 files, as well as for Web-accessible images in a variety of formats;
  • Configurable server-side, file-based caching;
  • Ajax-based client reference implementation, based on IIPImage JavaScript Viewer, which allows panning, zooming, and selecting the URI of the current view.

3.1. JPEG 2000 as the Service Format

The JPEG 2000 image format has attracted considerable attention among others due to its open specification, and its rich feature set defined in a multi-part ISO standard [6,8,9]. Features of interest in the context of this article are:

  • Multiple Resolutions: When compressing a master image, JPEG 2000 uses the multi-resolution attributes of the discrete wavelet transform (DWT) to store multiple DWT levels. In djatoka, the number of DWT levels is determined by the number of times an image can be halved from its maximum resolution's longest side to 92 pixels or less.
  • Region Extraction: The structure of JPEG 2000 files supports region decoding such that only the image data needed to render a sub-region is decompressed for display (Figure 1).
  • Compression: Support for lossless and lossy wavelet-based compression.
  • Self-containedness: Support for embedding XML metadata within the image bitstream, which may be used for licensing information, provenance description, descriptive metadata, etc.
  • Progressive Transmission: This allows a viewer to display a lower quality version of the image as soon as a small part of the entire image file has been received; the image quality then improves progressively as the downloading proceeds. JPEG 2000 supports progressive transmission in two dimensions: by pixel accuracy and by image resolution.

Image showing parameters for a JPEG 2000 Region Estraction

Figure 1: The X, Y, W, H parameters of a JPEG 2000 Region Extraction

Although Web browsers currently do not provide native support for JPEG 2000, the format is starting to find its way into mainstream applications such as Apple's QuickTime, Apple's Preview, Yahoo's Instant Messenger, etc. JPEG 2000 is also used as the core image format in the Google Book projects [10]. Also, at this point, over 100 organizations have taken out full commercial licenses to build and sell applications based on the JPEG 2000 Kakadu SDK. In the cultural heritage sector, JPEG 2000 is now seriously considered as a possible format for digital preservation (the image master), not only as a service format [11,12,13]. The aforementioned characteristics, combined with the availability of inexpensive Kakadu licenses for non-commercial use, made us decide to use JPEG 2000 as the service format for djatoka.

3.2. Architectural Overview

We describe the overall architecture of the solution by explaining the steps involved in a dissemination request issued from our Ajax-based client reference implementation (Figure 2).

Let's assume our Ajax client issues the first request to view an image that resides in the djatoka environment. The client starts by issuing an HTTP GET requesting metadata (e.g., width, height, DWT levels) for the image from the djatoka resolver. Details of the metadata-carrying HTTP URIs [14] used in djatoka are provided later, but it suffices to mention that they contain an identifier of the image and parameters detailing the specific dissemination that is requested for the identified image. In the case of an initial metadata request, the djatoka resolver responds with a JSON (JavaScript Object Notation) object containing image metadata, which the viewer uses for layout purposes. The djatoka reference implementation uses this information to calculate the center of the object and the number of 256x256 pixel tiles that will be necessary to fill a fixed-size viewport region.

The client will initially display a view of the image filling the existing viewport. A user can then zoom-in and explore regions by using common interface tools such as a navigatable reference image, zoom-in, and zoom-out buttons. The process to display a specific viewport always starts with the client determining the y,x offset values and resolution level for each of the 256x256 tiles necessary to fill the viewport. For each tile, an HTTP GET is issued against the djatoka resolver requesting a Region (Step 1 in Figure 2). This getRegion HTTP GET request carries the identifier of the image, the x,y offset, tile width and height parameter values, and optionally the desired image format for display (default JPEG) and the rotation degree (default 0).

Chart showing the steps involved in requesting a Region of a JPEG 2000 image from djatoka

Figure 2: Requesting a Region of a JPEG 2000 image from djatoka

For each of the incoming HTTP GET requests, the resolver parses off the image identifier and the service parameters, and passes them on to the djatoka API (Step 2 in Figure 2). There, the image identifier is resolved to the file path of the corresponding JPEG 2000 image. Then the Kakadu library is called (Step 3 in Figure 2). The Kakadu library requests the file handle for the provided JPEG 2000 image file path (Step 4 in Figure 2), and subsequently returns the requested Region at the specified resolution level and rotation degree as an uncompressed PNM (portable anymap) file to the djatoka API (Step 5 in Figure 2). The djatoka API then transforms the PNM file to the requested image format (default JPEG) and performs any additional transformations (e.g., watermarking) that might have been specified. The resulting image is then returned to the resolver (Step 6 in Figure 2) and from there on to the client. The multiple images resulting from the HTTP GET requests for individual 256x256 tiles are seamlessly joined in the user interface using CSS and JavaScript.

The process described so far assumes the existence of a JPEG 2000 image managed by the djatoka environment, i.e., the HTTP GET request carries an image identifier that the djatoka API can resolve to a file handle. However, djatoka also supports providing the URI of any web-accessible image as the image identifier. In this case, the djatoka API will obtain the image by dereferencing the URI and dynamically converting it to a JPEG 2000 file that is stored locally. In the djatoka environment, the image URI will then be associated with the image's file path, which allows the image's URI to be used in the HTTP GET for a requested Region. It is up to the djatoka implementation to decide on the lifetime of the local copy of these Web accessible images.

3.3. URIs for Reuse

When it comes to the reuse suggested by Andy Powell, off-the-shelf tools typically don't go beyond offering the ability to embed an entire image in a remote page, either as a stand-alone image or as an embedded object (e.g., an applet). However, a trend is emerging to support URI-addressability of a specified Region. For example, both Luna Imaging's Media Manager and the Harvard University Library Image Delivery Service support identification and Region Extraction by means of home grown HTTP URI syntaxes (see [15] for Harvard's syntax). As we show below, djatoka continues this trend and offers URIs for a wide variety of image disseminations. Considering the widespread use of high-resolution images, the availability of a standardized syntax to request Regions or other services pertaining to JPEG 2000 images from an image server would be rather helpful. Since the URIs used for Region Extraction or to get metadata clearly serve the purpose of (dynamically) requesting services pertaining to an identified resource (the entire JPEG 2000 image), we felt that NISO Z39-88.2004 "The OpenURL Framework for Context-Sensitive Services" [7] provides a standardized foundation that could be leveraged in this realm. Below, we give details about the basic JPEG 2000 OpenURL Application that we defined for this purpose.

The djatoka URIs for a Region
Image reuse was high on our priority list, and hence we devised a solution that is quite generous in providing URIs to identify image Regions:

  • The URI of the currently displayed viewport is inserted in the viewer in a YouTube-style copy-and-paste box. It is an HTTP URI requesting a Region that follows the same syntax conventions as the tile URIs. In order to specify the correct URI, the y,x inset values associated with the top-left pixel, as well as the height and width of the viewport are used.
  • As described above, each image tile used to display a specific Region of the image has its own HTTP URI since it is itself a (sub) Region. Currently, these URIs are not visible in our client implementation, but the search is on for an interface approach that allows capturing these URIs but does not clutter the displayed region. Also, we plan to include a discovery link in the HTML viewer page that points at an ORE Resource Map [16] that describes an ORE Aggregation in which the Aggregated Resources are the displayed Region and each of the tiles of which it consists. This Resource Map, expressed in RDF/XML [17] or Atom [18] will list the URIs of the Region and each of the individual tiles. In addition, it could express the copyright regime under which each is available, for example by means of a Creative Commons license URI, allowing automatic decision-making about rightful reuse.
  • When the image is external to the djatoka environment, yet Web-accessible, the aforementioned URIs are also available. This means that, although the source image itself is only accessible in its entirety at its native URI, djatoka will mint a new URI for the Regions and tiles it disseminates.
  • Since the HTTP URIs used in djatoka express a variety of parameter values with understandable parameter boundaries, a Region's URI can be guessed [14] and even algorithmically computed.

The OpenURL syntax for URIs to request disseminations from JPEG 2000 images
We defined a basic JPEG 2000 OpenURL Application in which an OpenURL Resolver is any JPEG 2000 image disseminator that adheres to the specifics described here.

  ContextObject Entity
  Referent ServiceType ReferringEntity Requester Resolver
Identifier 1 1 0 0 0
Metadata 0 1 0 0 0
Private Data 0 0 0 0 0

Table 1: The Entities of the ContextObject and their Descriptors for the JPEG 2000 OpenURL Application

The OpenURL ContextObject carries information only about a Referent and a ServiceType (Table 1). The Referent is the JPEG 2000 image, unambiguously described by its identifier. Currently, only two ServiceTypes are defined and identified as follows:

  • info:lanl-repo/svc/getRegion: the service to request a Region;
  • info:lanl-repo/svc/getMetadata: the service to request image metadata.

Note that these identifiers are currently in a LANL-owned namespace, but could obviously be defined elsewhere. In addition, a Metadata Format is defined specifying the parameters that can be conveyed in a Region Extraction request. Awaiting community feedback, it is currently registered for Trial Use in the OpenURL Registry with identifier info:ofi/fmt:kev:mtx:jpeg2000, and its so-called Matrix definition is available at <>. For convenience, the proposed parameters and their meaning are also shown in Table 2.

Parameter Description
format String. Mime type of the image format to be provided as response. Default: image/jpeg
rotate Integer. Rotates image by 90/180/270 degrees clockwise. Default: 0
level Integer. Where 0 is the lowest resolution with each increment doubling the image in size. Default: Max level of requested image, based on the number of Discrete Wavelet Transform (DWT) decomposition levels.
region Format: Y,X,H,W. Y is the down inset value (positive) from 0 on the y axis at the max image resolution. X is the right inset value (positive) from 0 on the x axis at the max image resolution. H is the height of the image provided as response. W is the width of the image provided as response. All values may either be absolute pixel values (e.g. 100,100,256,256), float values (e.g. 0.1,0.1,0.1,0.1), or a combination (e.g. 0.1,0.1,256,256).

Table 2: The Metadata Format specifying parameters to request a Region

A concrete HTTP URI OpenURL to request a Region is shown in Table 3. As can be seen, the identifier of the image for which a region is requested is info:lanl-repo/ds/CB_TM_QQ432, the svc_id parameter indicates the request for a Region, and the svc_val_fmt parameter specifies that the aforementioned Metadata Format is used to specify further details about the service request: values for the format, level, rotate and region parameters are provided. The Table also shows an OpenURL to request metadata about the same image.

Service Request URI (OpenURL)
Obtain Region
    url_ver=Z39.88-2004 &
    rft_id=info:lanl-repo/ds/CB_TM_QQ432 &
    svc_id=info:lanl-repo/svc/getRegion &
    svc_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000 &
        svc.format=image/jpeg &
        svc.level=4 &
        svc.rotate=0 &
Obtain Metadata
    url_ver=Z39.88-2004 &
    rft_id=info:lanl-repo/ds/CB_TM_QQ432 &

Table 3: OpenURLs to request a Region and Metadata for an image

3.4. Key Features

djatoka is open source Java software that builds upon a rich set of APIs and libraries to provide a service framework for the dynamic dissemination of JPEG 2000 image files (Figure 3). The djatoka API provides:

  • Compression of JPEG 2000 files using the Kakadu JPEG 2000 Library with properties to improve extraction performance and good compression/quality balance [19];
  • Dynamic extraction of multiple resolutions and Regions from JPEG 2000 files;
  • Support for a rich set of input/output formats (e.g., BMP, GIF, JPG, PNG, PNM, TIF, JPEG 2000) through the use of the ImageJ, Java Advanced Imaging, and the Kakadu JPEG 2000 Library;
  • Extensible interfaces to request image services and manipulations (e.g., watermarking);
  • A rich service framework, based on the OCLC OpenURL Resolver, to facilitate the transfer of service parameters via an OpenURL compliant HTTP GET request.
  • Configurable File-based Caching for improved performance.

Chart displaying the djatoka software environment

Figure 3: The djatoka Software Environment

djatoka is distributed under a GNU Lesser General Public License. The reference implementation Ajax-client is based on the IIPImage JavaScript Viewer, and is distributed under a GNU General Public License. Kakadu JPEG 2000 binaries are provided and installed with djatoka for non-commercial use only.

The djatoka solution requires a Linux/UNIX/MacOS-X/Windows operating system with Java 2 Standard Edition 1.5+ and Apache Tomcat 5 installed. For improved performance during compression and extraction, a system with 1GB+ RAM and multiple CPU cores is suggested. The djatoka software and additional documentation is available at <>.

3.5. Demonstration

We were fortunate to find two renowned institutions willing to collaborate on demonstrations illustrating the capabilities of djatoka.

The British Library has launched a pilot project to evaluate the use of djatoka as a platform for serving its rich image collection, and plans to provide an access point via its digital preservation site. At this point, we have hosted some of the British Libraries' images on our LANL demonstration server at <>. We are proud to temporarily host the Magna Carta, and provide it with a virtually infinite amount of URIs for Web 2.0 style reuse.

The University of Ghent has deployed a djatoka installation, and has made a selection of digitized pages of the Gregorian choir book Antiphonary Tsgrooten [20] available at <>. Below is an image showing a detail of the Gregorian choir book as seen through our Ajax viewer (Figure 4). The entire digitized book served from a commercial image server is also available for exploration (see [note 3] for a JavaScript-driven HTML viewer, and [note 4] for a Flash-based viewer).

We have also recorded a screencam that illustrates the capabilities of the current djatoka environment; it is available at <>.

Image showing a detail of Folio 69

Figure 4: A detail of Folio 69 of the Antiphonary Tsgrooten served by djatoka

4. Future Work and Call For Collaboration

We previously mentioned a specific addition to djatoka that is on our wish list, namely the inclusion in the client HTML page of ORE Resource Maps listing the URIs of the displayed Region and all of its tiles. The development of rich open source client interfaces is also high on our list of desired features. Additionally, we would like to explore the use of dynamic watermarking, both visible and invisible, as well as integration with popular repository systems.

This article introduces the first release of djatoka, and we understand that adopting communities will want to extend its functionality to meet the requirements of their use cases. We would very much welcome community contributions to help extend djatoka's capabilities, and invite participation in the djatoka project. We feel that the flexibility offered by both OpenURL and OCLC's OpenURL package provides a solid basis for adding image dissemination services on the basis of the same architectural framework. Another area of work for which we would welcome community feedback is that of the proposed OpenURL Application: are the ServiceTypes and the Metadata Format that we propose a good starting point, and which additional ServiceTypes and Metadata Formats are required to meet a variety of use cases?

5. A Diversion about OpenURL

When it comes to OpenURL, we also feel the time has come to thoroughly think about the standard itself. The JPEG 2000 OpenURL Application described above is just one example of HTTP URIs that carry another URI as metadata. As reuse of Web resources across applications increases, these kinds of URIs become more common. Take for example, the HTTP URIs used to share a specific blog entry with services such as Connotea,, Facebook, Furl, MySpace, Newsvine, Technorati, etc. All those URIs fulfill the same role but are expressed using a different syntax. There is such an abundance of syntaxes that ShareThis stepped in offering the convenience of a single syntax for a sharing-URI that points at ShareThis, where it gets translated and forwarded to one of the aforementioned environments. The OpenURL Standard provides a powerful framework that can be used to provide a standardized solution to these kinds of common problems. But, no such thing is going to happen. Generally, the NISO standards are hard to find on the Web, and their existence is hardly known outside of the library community. More specifically, the OpenURL Standard is rather unwelcoming because of its highly generic nature, its exotic terminology, and its non-intuitive syntax for the basic Key/Encoded-Value HTTP OpenURLs. The URIs of Table 3 adequately illustrate the complexity.

For quite some time, OCLC's Jeff Young has been speaking about the OpenURL Framework in terms of Q6 [21], the six core questions: What, Why, Who, Where, How, and When. The first five questions map directly to core concepts of the OpenURL Standard (Referent, ServiceType, Requester, ReferringEntity, Transport), and the last one is surprisingly missing from it. We believe Q6 is a very promising approach that, if executed properly, could give OpenURL a real chance of adoption beyond the initial target community. We would very much welcome community collaboration around these ideas.

6. Conclusion

With this article, we launch the djatoka image server, an extensible dissemination platform built around the JPEG 2000 format. The current version of the software is available for download from <>. We hope that the community will embrace the platform and will engage in extending it to meet the requirements of a variety of use cases. We very much welcome feedback regarding both djatoka, and the JPEG 2000 OpenURL Application that is proposed to try and establish interoperability among JPEG 2000 image servers.


The authors thank the following people for commenting on early drafts of this article: Jeroen Bekaert, Patrick Hochstenbach (University of Ghent), Michael L. Nelson (Old Dominion University), Jeff Young (OCLC Research).

The authors thank Adam Farquhar (British Library) and Patrick Hochstenbach (University of Ghent) for their enthusiastic involvement in preparing demonstrations for the first release of djatoka.


[1] Powell, A. (2008, March 17) Hiding The Magna Carta on the Web. eFoundations. <>.

[2] Magna Carta. Cotton Augustus ii. 106. Collection of the British Library.

[3] Van de Sompel, H., Bekaert, J., Liu, X., Balakireva, & L., Schwander, T. (2005). aDORe. A modular standards-based Digital Object repository. The Computer Journal, 48(5), pp. 514-535. <doi:10.1093/comjnl/bxh114>.

[4] Van de Sompel, H., Chute, R., Hochstenbach, P. (In Press). The aDORe Federation Architecture. International Journal on Digital Libraries. Preprint at <arXiv:0803.4511>.

[5] Murray, P. (2008, February 28). JPEG2000 to Zoomify Shim – Creating JPEG tiles from JPEG2000 images. Disruptive Library Technology Jester. <>.

[6] International Organization for Standardization. (2004). ISO/IEC 15444-1:2004: JPEG 2000 image coding system: Core coding system. <>.

[7] National Information Standardization Organization. (2004). ANSI/NISO Z39.88-2004: The OpenURL Framework for Context-Sensitive Services. <>.

[8] Marcellin, M.W., Gormish, M.J., Bilgin, A., Boliek, M.P. (2000). An overview of JPEG-2000. Proceedings of the IEEE Data Compression Conference, pp. 523-541. <doi:10.1109/DCC.2000.838192>.

[9] Bernier, R. (2006). An Introduction to JPEG 2000. Library Hi Tech News, 23(7), pp. 26-27. <doi:10.1108/07419050610704349>.

[10] Langley, A., Bloomberg, D. (2007). Google Books: Making the public domain universally accessible. Proceedings of the International Society for Optical Engineering, Vol. 6500. <doi:10.1117/12.710609>.

[11] Buonora, P., Liberati, F. (2008). A Format for Digital Preservation of Images: A Study on JPEG 2000 File Robustness. D-Lib Magazine, 14(7/8). <doi:10.1045/july2008-buonora>.

[12] Lamolinara, G., Mckee, B. (2007, October 25). Library of Congress Collaborates with Xerox To Test Format for Digitally Preserving, Accessing Treasured Images. News from the Library of Congress. <>.

[13] Murray, P. (2007, February 26th). JPEG2000 for Digital Preservation. Disruptive Library Technology Jester. <>.

[14] Mendelsohn, N., Williams, S. (2007). The use of Metadata in URIs. W3C TAG Finding, 2 January 2007. <>.

[15] Harvard University Library Image Delivery Service. (2007) Linking to JPEG2000 Images in the DRS. <>.

[16] Lagoze, C., Van de Sompel, H., Johnston, P., Nelson, M., Sanderson, R.;,Warner, S. (eds.) (2008) ORE Specifications and User Guide. <>.

[17] Beckett, D., McBride, B. (eds.) (2004). RDF/XML Syntax Specification (Revised). W3C Recommendation, 10 February 2004. <>.

[18] Nottingham, M., Sayre, R. (eds.) (2005, December) IETF RFC 4287: The Atom Syndication Format. <>.

[19] Lepley. M. (2008). JPEG 2000: fast access to large grayscale images. Proceedings of the International Society for Optical Engineering, Vol. 6943, 69431B. <doi:10.1117/12.777178>.

[20] Antiphonary Tsgrooten (manuscript on parchment, 1522; provenance: Brabant, region Antwerp, Malines, Louvain); 338 folios; 620 x 425 x 150 mm. Gent, University Library, Collectie Vlaanderen BKT006.

[21] Young, J. (2006, August 7) Welcome! Q6. <>.


[1] Magna Carta via the British Library HTML viewer <>.

[2] Magna Carta via the British Library Shockwave viewer <>.

[3] Antiphonary Tsgrooten via the University of Ghent HTML viewer <>.

[4] Antiphonary Tsgrooten via the University of Ghent Flash viewer <>.

Copyright © 2008 Ryan Chute and Herbert Van de Sompel

Top | Contents
Search | Author Index | Title Index | Back Issues
Editorial | Letters | Next Article
Home | E-mail the Editor


D-Lib Magazine Access Terms and Conditions