What's Neat and New
in Pano Two
By Kurt Conrad, The Sagebrush Group
Abstract
Panorama was one of the first commercial applications to use and support the HyTime Standard. SoftQuad is completing a major revision of the package. This presentation will provide an overview of Panorama Pro version 2, now in beta release, and highlight the changes from the previous version.
Overview
SoftQuad is making a number of useful improvements in Panorama Pro, Version 2 (PPv2). These include:
- Conversion to ViewPort technology
- Integrated HTTP client
- Forms
- Frames
- Querying Enhancements
- Improved Graphics Support
- Background Images
- Processing Instructions for Webs
- Point Specifications (instead of pixels)
ViewPort
The most significant technical changes between Panorama 1.x and 2.0 result from the "rebuilding" of Synex's SGML/HyTime browser engine (ViewPort). Both Panorama 1.x and 2 were built on top of ViewPort. The engine was rebuilt, primarily, to meet the need for cross-platform support and it now supports both 16- and 32-bit implementations. ViewPort comprises a c++ kernel and c API that was based on the original Explorer code, and was designed to isolate operating system dependencies to make it easier to support different hardware, software, packaging, and/or user interface needs.
Because of the magnitude of this change, a number of features that worked well in version 1.5 have had bugs introduced. Most of these have been minor and are expected to be resolved by the time that the product is released. Macintosh and UNIX versions are expected to be finished within a few months of the 16 and 32-bit Windows releases. Because the development of and conversion to ViewPort has been the primary technical effort, version 2.0 doesn't have as many feature enhancements as might be expected. Although the conversion to ViewPort is a largely hidden change, it is an important one and promises to accelerate the implementation of versions for other platforms, the addition of new features, and enhancements to the user interface.
HTTP Client
Panorama 1.x was dependent on a "registered" Web browser for HTTP services and could not communicate directly with Web servers. This meant that it could only work with a handful of Web browsers and had a fairly tricky installation process. If, for example, you installed Panorama and the Web browser in the wrong order or upgraded your web browser, you might "break" Panorama.
Now, with its own HTTP client, Panorama can be used with any Web browser that can launch helper applications. This makes Panorama's installation and configuration much more straightforward and reliable, closely matching that of other helper applications. In time, it might even mean that HTML browsers could be launched as helper apps to Panorama.
Forms
PPv2 supports HTML forms. This is done by using the "Widgets" entry in the styles editor to register the appropriate forms objects (html.imput, html.select, and html.textarea). In addition, the standard HTML form element type names should be retained because Panorama bases some of its processing on them.
Frames
From one perspective, the addition of frames has a strong "Netscape? Me too!" feel to it. On the other hand, Panorama's frames feature goes quite a bit beyond that offered by HTML browsers. It is based on a superset of Netscape's frame specification, and where Netscape only maps the contents of an entire file (a different file) into a frame, Panorama provides more flexibility and allows you to specify any of the following to be used as the content of a frame:
- a file that has been identified through a system identifier or URL
- an external file entity
- an element that has been identified by its ID
- an element that has been identified through TEI location syntax
- a navigator
A number of different frame approaches are possible. In perhaps one of its simplest applications, a navigator/file combination could be used to replicate the "traditional" Panorama screen layout. By using frames, however, you could control the size and position of the navigator to have it displayed to the right, above, or even below the main document window.
A slightly more sophisticated approach could be to place a banner across the top of the viewing area that contains the title of the document. Elements like these, which are to remain fixed throughout the viewing session, can be identified by their ID.
An even more impressive application of frames is to use them to display elements which are to be replaced during the viewing session, lets say individual chapters of a large document. In these applications, a default chapter element is identified by its ID and when different chapters are selected through the navigator, they take the place of the previously displayed chapter.
TEI locators can also be used to select specific elements for display in a frame. Extending on the previous example, it is possible to fill a frame with "the first title element" so that the current chapter title is always displayed in its own frame, regardless of what portion of the chapter is viewable.
In addition, multiple frames can be used to display additional navigators, each being synchronized with and updating the main document window.
The biggest problem that I have with frames is that frame specifications have to be placed in the document instance. This means 1) the document's DTD has to include the frameset and supporting element declarations; 2) Panorama doesn't provide an interface to support the definition and creation of frames and their attributes; and 3) a single instance cannot be used for both framed and non-framed views or for multiple frame specifications. In fact, the restrictions don't end there. The frameset element has to be the first child element in the document instance.
In the future, it would be nice if the set of metadata which is used to define and specify frame behaviors could be stored outside of the instance and be configured from within Panorama's GUI environment.
Querying Enhancements
PPv2 will support regular expressions (which are based on a subset of the TEI specification) in the search function. I have been hoping for an improved user interface that helps to construct sophisticated searches without learning a complex query language. There is a good chance of such an interface appearing in the future, but not in PPv2. In the meantime, PPv2 has added a Previous Search field to help construct and fine tune complex queries. This allows up to six queries to be recalled, edited, and reinvoked.
Improved Graphics Support
PPv2 incorporate a new graphics library which expands the file formats which can be rendered inline to include:
- Windows and OS/2 Bitmap (BMP)
- CCITT Group 3 and 4
- Computer Graphics Metafile (CGM)
- Encapsulated Postscript (EPS), if the file contains an embedded TIFF image
- Graphic Interchange Format (GIF)
- Joint Photographic Experts Group (JPEG)
- Portable Bitmap (PBM)
- Portable Network Graphics (PNG)
- Tagged Interchange File Format (TIFF)
- Windows Metafile (WMF)
In addition, the graphics subsystem will automatically detect the file format, although actually using such an approach would violate many of the SGML religion's core precepts.
Background Images
Yep. Panorama now supports background images. Which means that if you haven't been able to make your pages hard enough to read with poor color combinations, you can now try noisy graphics. Background images are specified by entering "\pattern(<icon name>)" in the background color field.
Processing Instructions for Webs
In PPv2, webs are no longer just local to the user. The new version will allow webs to be attached to a document via processing instructions. This allows webs to be used for published sets of hyperlinks because their loading can be controlled by the publisher. Prior to this, the user would have to explicitly attach the appropriate web(s).
Point Specifications
With PPv2, font sizes and spacing specifications will be interpreted in terms of points (not pixels). While this improves conformance with traditional typography and should solve a number of printing problems, it may mean that old style sheets will need to be adjusted to bring the sizing back down to what it was before.
Conclusion
If SoftQuad succeeds in delivering cross-platform support, PPv2 will be a significant addition to the community of commercial SGML tools. Still, it is hard not to be a bit disappointed with the lack of changes to the user interface. Options that required the user to know, understand, and type complex syntax into text fields have gone essentially unchanged and even been augmented in new features (background images, for example). Even simple changes to the user interface (like using the word "points" on those screens that used to accept specifications in pixels) were not executed.
In addition, SoftQuad seems to be having trouble deciding where to position Panorama. The original vision, of an SGML browser for the Word Wide Web, appears to have fallen to the side, as Panorama has found a greater market in corporate intranets. For example, PPv2 supports a number of options in the Panorama.ini file that are not of much use in the Internet, but appear to have resulted from input from corporate customers. In addition, the intended relationship between Panorama and Web browsers appears unclear, as are plans on whether or not to update the freeware version and what level of functionality a free version of Panorama should have.
It only took five pages to describe the changes from version 1.5 to 2. Two or even three times the space could have been devoted to describing refinements to the existing user interface. Here's to the hope that with the ViewPort engine having been rebuilt, energies can be focused on the user interface and functionality changes that would be expected in a major release.