Options for printable versions of PIE pages

How the PIE renders HTML pages

Each PIE page consists of a hierarchy of items, pages containing lists containing resources, for example. Each of these items has two states, expanded and contracted, and pseudo-HTML is stored in the PIE database for each of these two possibilities. The reason that standard compliant HTML is not stored is so that the pages can include values of variables (e.g. user identity), information from the database (e.g. the title of the current page), and information about the hierarchy of items (e.g. put child items in this table cell). The HTML is generally in the form of complicated tables, to ensure some consistency of layout, but doesn't have any very recent innovations (such as layers) or script to ensure consistency on a variety of browsers.

What do we mean by printable pages?

The purposes of printable versions of PIE pages are several. They could be used by librarians to produce lists of resources of various types (e.g. relevant to economics, accessible off campus), or by lecturers to produce reading lists. These purposes are likely to be present in any institution at the same time, and their desired appearance will be different. Thus, just having one printable version of a page is not enough.

In order to be able to produce multiple printable versions of pages, we need to be able to specify the layout of these pages quite minutely and simply. This is particularly the case if we don't want to try to guess what type of pages users might want in the future. The sort of software available includes XML/XSL processors for the Apache web server.

Approaches to printable pages

• The simplest approach to implement would be to make only a single printable form available. This is so much easier to do that it is worth considering, even though it fails to meet the criteria listed above. It would probably most easily be done by adding a third possible type of HTML to the PIE database, so that items could be expanded, contracted or printable. (Note: The HTML table is currently pushing the limits of the capabilities of postgres 6.0, because it has a 2000 character transaction limit. So some way would have to be found around this - such as putting the HTML in configuration files - before this approach could be implemented, and this would mean that it would be more time consuming than it appears at first sight.)
• Use multiple HTML configuration files which allow the creation of different types of pages. For each type of item, the system would initially have an item_expanded.html and an item_contracted.html; to add printable pages you could add files like item_readinglist.html and item_resourcelist.html. These would then be available through links on each page to "Create reading list" and "Create resource list", the wording being linked via the main PIE configuration to the *_readinglist.html and *_resourcelist.html files respectively. This approach would be nearly as simple to code as the first one, and would offer exactly the flexibility that is needed. If a quick solution is needed, this is probably the best way to do it.
• In order to do the second option, the PIE will need to effectively reinvent some existing technology. Cascading Style Sheets and eXtensible Style Language effectively allow the appearance of a Web page to be separated from its content, and this is what the PIE is also doing. The third option, then, which is certainly the neatest, is to rewrite the PIE so that it produces XML output, which is then viewed via any one of several style sheets. The disadvantages of this option is that it will involve considerable rewriting of the PIE code, setting up the initial style definitions, and that the CSS2 standard is only properly supported by the Mozilla browser, not yet by any final release software. (Both Netscape Communicator and Internet Explorer support it partially, from versions 4.0 onwards.) XSL is an even more recent standard. See the CSS page and the XSL page at the W3 for more information and links.
• While the third option relies on the browser for the formatting, it is also possible to do this at the server side or via Java plugins to web pages, and this might allow more browser independence. This would need further investigation. See the XSL FAQ for a description of how XSL conversion can be done.