About
The HyperReader server attempts to read Bookreader format
documents and present them as hypertext documents. Sometimes it is very
successful, other times not! The reasons are few but significant:
-
Bookreader documents are not plain text.
They are not even marked-up text (in the same sense as HTML documents).
Essentially they are a series of images pasted onto an X window. Most of
the images happen to be from fonts, but even then characters are not
handled as text. There is essentially no information within the file on
the documentary function of any text in a book. This may be one reason
for the poor performance of the internal Bookreader print
functionality (it must adopt a similar mapping then "images" into
PostScript "pages").
-
Bookreader format is not public.
At least not that I could find. Hence considerable effort at reverse-
engineering the structure (most originally during January 1992
fortunately, I wouldn't have the patience, time or interest now!) In any
case, the structure is complex and I don't pretend to understand it all
... so the server tends to break occasionally.
-
Development time available.
Zero. However not being able to get to the wealth of Bookreader
documentation from the hypertext enviroment in some fashion (no matter how
primitive) seemed too great a deficiency not to make some effort.
Corollary: the server is not as fully developed (or debugged) as
might be desired.
Limitations
-
Client/Server Use.
Bookreader documents were never really designed to be accessed using
client/server technology. There are some "book opening"
overheads best done only once (as with the original Bookreader
application). With the HTTP (hypertext) environment these must be
performed with each access, sometimes introducing noticable latency.
-
Mapping of document text.
The server attempts to map a bit-addressed format (Bookreader) onto a
character-cell format (text-page). Bookreader formatting permits parts of
a page to be generated non-sequentially, for example to place normal text,
then place bolded text within it. This can occur on a per-line, per-
section or per-page basis. So the entire "page" for a hypertext
enviroment must be created by mapping into a "page" in memory. Sometimes
this mapping is not perfect and character strings get garbled or poorly
proportioned.
-
Fixed-Font presentation.
This is due to two requirements:
-
The mapping from bit-addressed to cell-addressed described above requires
a fixed character-cell matrix.
-
Maintaining correct layout for examples, tables, etc. As the Bookreader
format specifies the positioning of the document's components, rather than
information on their documentary function, relative location must be
maintained, generally eliminating the use of the more aesthetically
pleasing proportional fonts.
-
Image conversion and compression.
Figures and graphics within Bookreader documents are stored as
single-plane bitmaps. HyperReader supports these using GIF
compression or X-bitmap depending on the relative efficiencies for a
given image (i.e. icons may not warrant the overheads of GIF, whereas
larger diagrams obviously do). There may be some latency as a native
image is GIF compressed prior to transmission. Figure positioning on a
page can sometimes be clumsy, and is exacerbated by the inability of
current browsers to flow text around images.
-
Page layout.
Apart from the text-mapping process mentioned above, page layout can
sometimes be a little odd, particularly if graphics are involved.
Some massaging of the resulting page occurs. This often involves
educated guesswork. For instance, single blank lines preceding a line
beginning with a lower-case alphabetic are most often an artifact of the
mapping process rather than intended line breaks, and can be eliminated to
produce a better layout. Similarly, bulleted and numbered lists can be
enhanced by ensuring a blank line exists between elements. Unfortunately
there are not many instances where the original intent can be clearly
identified.
Finally ...
Even considering all the limitations of the approach it generally works
remarkably well, and does also give access to Bookreader documentation
from a character-cell terminal (via a browser such as Lynx).
I hope its useful.

Mark Daniel, November 1994