A localization system for library items using SVG

The implementation of a web application using SVG for the localization of library items

Egon Nijns
Software Engineer
Katholieke Universiteit Leuven
Campusbibliotheek Arenberg
Willem de Croylaan 6


Egon Nijns is currently employed as a Software Engineer at the Campus Library Arenberg, which is the library of exact sciences for the Catholic University of Leuven.

Ludo Holans
Katholieke Universiteit Leuven
Campusbibliotheek Arenberg
Willem de Croylaan 6

Olivier Van Kerrebroeck


As the ICT department of a modern university library one of our main goals is to minimize all the routine work of the library staff. With this goal in mind we analyzed the types of questions the library staff needs to answer during their day-time job. For the most frequently asked questions we provide as much information as possible on our website.

For questions like "Where do I find a book on topic A?", "Where do I find journal B?" or even "Where are the toilets?" this FAQ approach is inadequate. Since these repetitive questions are asked daily we decided to build a localization tool. To accomplish this we needed some type of interactive visualization of the library stacks and floors. We decided to use SVG because it is a very promising open-standard web-based technology.

Through the use of SVG and the SVG DOM API we are able to provide an interactive two-dimensional interface. This interface allows our users to explore the library building or search for one specific library item. We use a database that holds all the locations of the library items in the building. The system responds to "Where do I find journal B" by highlighting a specific rack on the floor plan. When this rack is clicked the system dynamically generates a detailed SVG image that shows the content of the rack.

Our application, called "Locator", works in SVG-enabled Mozilla builds as well as in Internet Explorer with the Adobe SVG plugin. An administrative interface allows the librarians to keep the information in the database up-to-date.

Future challenges include improving the usability of the application, making it easier and faster for librarians to keep locations up-to-date. One of the key issues here is that we don't want to reload SVG images whenever we need to consult or update the database.

Our paper describes the application in detail and also discusses some improvements which we plan to implement in the near future.

Table of Contents

1. Introduction
     1.1 Short history
2. The use of SVG in our localization system
     2.1 Why we chose SVG
     2.2 Problems with the use of SVG
          2.2.1 Possible solutions for our problem
     2.3 The Mozilla SVG project
3. Technical architecture of the "Locator" application
     3.1 Technologies
     3.2 Putting it all together
     3.3 Porting our application to work with Mozilla's native SVG implementation
          3.3.1 Embedding SVG graphics in web pages
          3.3.2 JavaScript modifications
     3.4 Future enhancements
          3.4.1 Database redesign
          3.4.2 The usage of the XMLHttpRequest JavaScript object
4. User interfaces
     4.1 User interface for the library visitors
     4.2 Librarians' update interface

1. Introduction

In an academic library the size of ours, with more than 220.000 volumes in open access, and where the monographs are not put on the shelves in a normal order according to the classification scheme but are clustered by different disciplines, the retrieval of books and journals is only evident to the library staff. This is why the library decided to build a system that guides its patrons through the building and shows them on a floor plan where exactly they can find the specific book they are looking for.

1.1 Short history

During the academic year 2001-2002 Olivier Van Kerrebroeck, at that time a last year's student Master in Computer Sciences, was doing his thesis research for the to-be-build Campus Library Arenberg. Ludo Holans, head librarian, suggested an application that would guide people through the large library of more than 10.000 square meters. The possibility for library visitors to virtually explore the building from behind their computer screens should be foreseen. Furthermore he wanted searching capabilities for specific categories of books making use of their UDC classification codes [W17] or corresponding key words. He preferred a web application, to increase the usability and also because this would increase the library's visibility to the outside world.

Olivier's research resulted in a working prototype of this localization application, that was given the name "Locator". This prototype used an Oracle database and ran locally on Olivier's desktop. He described his research in his thesis Visualization and retrieval by means of 2D-images of systematically arranged books in the open stacks collection of the new Campus Library Arenberg of the KULeuven. [B4]

The implementation was planned for the end of 2002 and thus the application had to be ported to a server. At the same time we decided to change the underlying Oracle database to a MySQL one. This decision was made because of the licensing cost of the Oracle database and because we already had some experience with MySQL. We also rewrote the user interface and created an update section.

2. The use of SVG in our localization system

While trying to meet the specifications for this application we needed some type of visualization of the library. First we analyzed some of the existing visualization techniques for the web such as image maps, DHTML, Flash... Mostly because the application had to be database-driven we soon realised that we needed an interactive vector format. Flash was an option, but we were lucky enough to stumble upon a new vector image format. As it was backed by the W3C, support by the major web browsers seemed a reasonable assumption. Of course we are talking about Scalable Vector Graphics here.

We used the 2D images of the floor plans that were also used for the construction of the building as a source for the SVG files that visualize the library.

2.1 Why we chose SVG

SVG was chosen because:

2.2 Problems with the use of SVG

The main problem is that since SVG is a relatively new technology, support for SVG is still growing. We will explain our specific situation, and the consequences for the use of our 'localization application' in detail in the next paragraph.

The library network is made up of approximately 100 Sun Rays [W3], connected to a Sun Ray Server. This setup runs on the Sun Solaris operating system. The Sun Rays are the machines that our library visitors use in our library, so we need to be able to run the "Locator" on them. This setup was chosen because of the ease of maintenance of the system. The prototype of the "Locator" was build before the choice of this system was made. The problem is that this prototype was build to work 'only' in Internet Explorer with the Adobe SVG plugin, and this combination is not available for Solaris.

There has been a Beta version of the Adobe SVG plugin for Mozilla on Solaris, but it did not allow scripting from HTML to SVG. Since this property of SVG is used heavily in our application we could not use this plugin.

As a consequence, we were unable to offer the application to our patrons while working in the library, which in fact destroyed its very raison-d'etre. This forced us to start looking for possible solutions or alternative approaches.

2.2.1 Possible solutions for our problem

Several solutions have been considered to deal with our specific problem:

2.3 The Mozilla SVG project

After reading the following on the Mozilla SVG project's web site, we knew that this would be the ideal path for us to take...

“The goal we're working towards with Mozilla's SVG implementation is SVG 1.1 Full. What exists now in the tree should be treated as a technology preview. [...] While we are still a long way away from full SVG support, the subset currently implemented is already pretty usable. We have support for all basic shapes including beziers, stroking and filling with opacity, gradients, scripting, events, and much of the DOM.”

This subset alone was almost sufficient for our application to work and because of the progress the Mozilla SVG project [W6] had made by the end of 2004, we decided to try to build Mozilla with SVG support on our system. When we succeeded with the build process for the first time (after several tries) we were finally able to test the Mozilla SVG support. For simple SVG files there were almost no problems viewing them.

On Wednesday April 13th 2005, seemingly out of nowhere, there was a Mozillazine article with the following title: “Publish: Mozilla Firefox 1.1 to Support SVG” This rumour was later confirmed by Robert O'Callahan and Jonathan Watt updated the Mozilla SVG Project FAQ to say: “If everything goes well, we hope to have SVG support included in Mozilla Firefox 1.1. There will be a user configuration preference (pref) to allow the support to be turned on or off, and our intention is that it should be turned on by default.”[W7] We believe that this is good news both for our localization application and for SVG in general.

In Section 3.3 we describe some things we had to do to make our application work with Mozilla's native SVG implementation.

We have some remaining problems with the Mozilla SVG implementation, most of them being specific for Solaris. The Mozilla SVG project decided some time ago to use the Cairo library as a backend for their SVG code on all platforms other than Windows. The Cairo library and the Mozilla SVG project itself are still progressing, so please keep in mind that some of the problems at the time of writing may be solved in the near future.

Some of these remaining issues are:

3. Technical architecture of the "Locator" application

3.1 Technologies

Our "Locator" application uses a number of technologies, which can be split up into two categories.

Server-side technologies:

Client-side technologies:

3.2 Putting it all together

The (new) structure of the database we use in our application is described in Section 3.4.1. The Servlets and JSP pages are used to search this database for specific locations and descriptions of UDC (Universal Decimal Classification) categories. After the SQL data retrieval, the JSPs will generate the HTML page including the floor plan SVG and all the search results in a table structure. A JavaScript function will then be used to highlight a specific bookrack on the floor plan. For this approach to work, we need the rack_ID that is used in the database to be encoded in the SVG files. More specifically, for each bookrack we used the rack_ID value as found in our database for the 'id' attribute of the path tag that represents that bookrack.

var svgDoc; 
var svg_rack; 

svgDoc = document.embeds['floor00'].getSVGDocument();
svg_rack = svgDoc.getElementById(rack_ID); 
if(svg_rack != null){
	svg_rack.setAttribute("fill", "red");
	svg_rack.setAttribute("fill-opacity", "1"); 

Example 1: JavaScript code to highlight one specific rack on the first floor

One shortcoming of our approach is that we can only visualize the results on one floor at once. The above code-snippet works in Internet Explorer with the Adobe SVG plugin as well as in the SVG enabled Mozilla builds. Some points of interest that one must keep in mind when writing JavaScript code that works in both of these browsers are described in Section 3.3.2.

3.3 Porting our application to work with Mozilla's native SVG implementation

“A not uncommon problem encountered by SVG authors who are testing their SVG documents in Mozilla for the first time is that the source of their SVG documents is shown instead of the graphic. One possible cause of this problem may be that the MIME-type being sent by the server for the SVG files is incorrect. At least some servers seem to send a default value of "text/plain" for text files with file name extensions that they don't recognise. If this is the case then Mozilla rightly respects the MIME-type sent by the server and displays the SVG files as text. Mozilla will only display SVG files correctly if the server sends the correct MIME-type of "image/svg+xml".”[W18]

We ran into this problem on a specific occasion where we were dynamically creating SVG images with JSP. Here we were able to solve this problem by setting the content type of that page dynamically using a JSP page directive [W19].

<%@ page contentType="image/svg+xml; charset=utf-8" %>

NOTE: Related to this problem we also had to use the following little trick to make Internet Explorer behave as expected. We appended ?IEHack=.svg to the filename of the dynamically generated file (with the extension .jsp) that we wanted to embed.

This solution is described on http://www.pinkjuice.com/howto/rubysvg/ as follows:

“Some IEs don't recognize the MIME type, but only recognize files whose name ends in .svg as SVG files. [...] When referencing/linking SVG files that have file name extension other than .svg, always append the IEHack to the URL: ?IEHack=.svg for example www.rubynewbies.com/~tobi/h_time.rb?IEHack=.svg[W20]

3.3.1 Embedding SVG graphics in web pages

3.3.2 JavaScript modifications

When writing JavaScript that has to work across different browsers, it is a good idea to try to conform to the ECMAScript standard (see [W2]). The JavaScript functions used in the prototype of the "Locator" did not conform to these standards, so we had to make some modifications to these JavaScript functions to make them work in Mozilla. A good starting point to find out about the required modifications is Mozilla's JavaScript console.

When writing JavaScript for Mozilla we have also used Venkman, which can be considered as a Mozilla JavaScript debugger. This tool has been a great help for all our JavaScript SVG work. [W9]

We found out that if we code our JavaScript to work with Mozilla's JavaScript engine, it generally conforms better to the ECMAScript standard, and most of the time works in Internet Explorer without modifications.

Here is a list with some pointers to modifications we had to make to our JavaScript functions.

3.4 Future enhancements

When building a web application, especially one using a new technology such as SVG, it is not uncommon that it requires a couple of modifications or even complete rewrites before it reaches a mature state. This is definitely true for the "Locator". In the following subsections we will describe some things we have in mind to improve our application. Some of these will be implemented in the near future.

3.4.1 Database redesign

The database that was used in the prototype version of the "Locator" was not flexible enough. To be more specific, the database did not allow for books and journals to be placed whatever place you would like in the library. For one thing this database structure assumed that journals would always be placed in the basement of the library, but in the end things turned out very different.

Our new database structure allows for journals and books to be placed anywhere in the library, and is in general somewhat more flexible than the old database. The following figure shows a schematic representation of our new database.


The 'racks' table in this scheme represents, unsurprisingly, the bookracks, and the 'udc_books' table holds all the different categories of books our library has. The table 'udc_journals' holds all the different journals our library is or was subscribed to. The table 'locations' connects the UDC tables to the 'racks' table, in essence locating all the UDCs. The 'display_locations' table does the same, but for a conceptually different type of rack.
Details about the different types of racks can be found in the rack_types table. These details are used when we draw the SVG that visualizes the contents of a rack in detail. An example of this can be seen in
Figure 9.

Figure 2: Database structure

3.4.2 The usage of the XMLHttpRequest JavaScript object

We already mentioned the slow loading times of the SVG files, especially in the SVG enabled Mozilla builds. But also in Internet Explorer with the Adobe SVG plugin it takes a while for our SVG floor plans to load. The big size of our SVG files is of course partially to blame. This is why we want to reduce the number of times the SVG files are loaded by the web browser to the absolute minimum. In the prototype version of the "Locator" every time we needed to query the database this required a page reload.

The use of the XMLHttpRequest object makes it possible to use JavaScript to post to a different page in the background and then use the output from that page in a JavaScript function. This function can then use the DOM to update only the relevant parts of the HTML page and modify the already loaded SVG file on the fly.

NOTE: A similar approach is also possible using postURL and getURL functionality, but these functions are only available in the Adobe SVG viewer plugin.

One could argue that the XMLHttpRequest is not supported by all web browsers, but the same is true for SVG. We believe that it is reasonable to assume that we can get the XMLHttpRequest object to work properly in all the modern browsers that support SVG. The fact that a popular service such as Google's GMail uses the same technology makes this assumption look quite reasonable.

The W3C SVG Full 1.2 Working Draft of October 2004 [W14] specifies similar functionality in a function named URLRequest, but for the time being our safest bet for doing this in a browser environment is using the XMLHttpRequest object.

4. User interfaces

After describing the technical details of our application, we will now proceed with a short description of the user interface of the application. We think that this is the best way to demonstrate how the "Locator" works and how it can be used. The first subsection describes the end user interface, whereas the second subsection shows how the librarians keep the application data up-to-date.

4.1 User interface for the library visitors


This first screenshot shows the browse floors section, where one can virtually explore the library building.
When clicking one of the location-links on the right, a specific location on the SVG will be highlighted and a short description will be shown.

Figure 3: Browse floors


The second screenshot shows the browse books section, the SVG shows the library's open stack collection of books.
The first time 'Show next cluster' is clicked, the bookracks of cluster 1 become highlighted.

Figure 4: Browse books

NOTE: Here is a short description of the concept of "clusters" as found on the library website.

The campus library Arenberg has arranged the book collection in 6 logical clusters or subdivisions. Clusters 1 to 5, can be found on the ground floor. Cluster 6, can be found on the first floor of the library.

A brief outline: Cluster 1: Electrical and Electronics Engineering, Mechanical Engineering, Mathematics, Computer Sciences and Safety Sciences. Cluster 2: Physics, Materials Science, Chemistry, Chemical Engineering Sciences, Geology, Astronomy, Physical Geography Cluster 3: Agricultural and Applied Biological Sciences, Zoology and Botany Cluster 4: Sports Sciences and Movement Sciences, Kinesiology, Revalidation, Physical Education and Physiotherapy Cluster 5: Civil engineering, Architecture, Urban planning and Environmental town and country planning, Social and Economical Geography Cluster 6: Didactics (Supervised self teaching, Undergraduate Library, Secondary teacher training) [W16]


Clicking on the camera icon in the SVG opens a picture pop-up.
We believe that this makes it easier for people to orientate themselves.

Figure 5: The use of pictures


This page shows a list of UDC categories per cluster. When a category on the right side is clicked, the bookrack(s) that contain that category of books are highlighted.

Figure 6: Detailed cluster overview


In the search section for the books we can search by keyword, and the application will retrieve all the UDC categories that have this word in their description.
We are looking for books on statistics.

Figure 7: Search by keyword


The application has found all the UDC categories that contain the word statistics in their description and highlights the bookracks in the SVG that contain these categories.

Figure 8: Search results


If one wants to have more details one can click on a specific bookrack in the SVG or click on a link in the results list.
In bookrack 8B we will find books of the category 'Statistics of dependent variables. Contingency tables' on the fifth shelf.

Figure 9: Detailed search results

4.2 Librarians' update interface

This part of the application turned out to be extremely important because moving books around happens more often than one would expect in a (new) library. This update section needs to be made as user friendly as possible, because we do not want to create unnecessary work for the librarians. Our application is database driven and can only work well if the data is kept up-to-date.


This page can be used to add or update specific UDC categories.

Figure 10: Updating UDC descriptions


Changing or adding locations requires some more input because the exact locations for the UDC categories need to be entered. These data are used to draw the bookracks in detail, as can be seen in Figure 9.

Figure 11: Database structure


Thanks to Olivier Van Kerrebroeck for his work on the prototype of the "Locator". Thanks to Ludo Holans for this great idea and for offering us the opportunities to make the "Locator" a reality. I would also like to take this opportunity to thank all the librarians for their efforts in helping me understand the library world and for their data input into the "Locator". Last but not least I would like to thank all the people involved in the Mozilla SVG project, for the great work that they are doing.


SVG Essentials Eisenberg J. David O' Reilly 2002
JavaScript The Definitive Guide 3rd Edition Flanagan David J. O' Reilly 1998
Building Java Enterprise Systems with J2EE Perrone Paul J. Chaganti Venkata S.R. "Krishna" R. O' Reilly 1998
Visualization and retrieval by means of 2D-images of systematically arranged books in the open stacks collection of the new Campus Library Arenberg of the KULeuven Van Kerrebroeck Olivier 2002
Het SQL leerboek 5de herziene druk, 2de oplage (licht gewijzigd) van der Lans Rick F. Academic Service 1999
Scalable Vector Graphics 1.1 Specification W3C Recommendation http://www.w3.org/TR/SVG11/ 14 January 2003
ECMAScript language specification (ECMA-262) 3rd edition http://www.ecma-international.org/publications/standards/Ecma-262.htm December 1999
Sun Ray Server http://www.sun.com/software/sunray/index.xml
Batik SVG Toolkit http://xml.apache.org/batik/
Java Applets http://java.sun.com/applets/
Mozilla SVG project Home page http://www.mozilla.org/projects/svg/
Mozilla SVG project Frequently Asked Questions http://www.mozilla.org/projects/svg/faq.html
Adobe SVG Viewer Download Area http://www.adobe.com/svg/viewer/install/main.html
Venkman JavaScript Debugger Home page http://www.mozilla.org/projects/venkman/
SVG FAQ JavaScript General http://www.svgfaq.com/JSGeneral.asp
KevLinDev Tutorials SVG http://www.kevlindev.com/tutorials/basics/miscellaneous/document/index.htm
IE -> Mozilla Guide for Web Application Developers DOM Differences http://nexgenmedia.net/evang/iemozguide/#dom_differences
W3C DOM Level 2 version 1.0 Interface CSSStyleDeclaration http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/css/CSSStyleDeclaration.html
Scalable Vector Graphics Full 1.2 Specification W3C Working Draft http://www.w3.org/TR/SVG12/ 13 April 2005
Cairo graphics http://www.cairographics.org/ 2005
Campus Library Arenberg http://www.wbib.kuleuven.be/ 2005
Universal Decimal Classification Consortium http://www.udcc.org/
Mozilla Wiki (SVG:MIMEType page) http://wiki.mozilla.org/SVG:MIMEType 8 June 2005
Sun JSP syntax reference (Page Directive) http://java.sun.com/products/jsp/tags/11/syntaxref11.fm7.html 1999
Generating and serving SVG with Ruby (basic) http://www.pinkjuice.com/howto/rubysvg/
Mozilla Wiki (SVG:Namespace page) http://wiki.mozilla.org/SVG:Namespace 14 June 2005

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.