Technical Aspects of the Electronic Edition

Introduction

Presenting a 16th-century manuscript written in polytonic Greek using 21st-century technology posed some interesting challenges, not the least of which arose from our determination to ensure that the work was accessible to all^[1] users, no matter where in the world, provided only that they had access to the Internet using a modern standards-compliant web browser. We had to tread a very fine line, neither exploiting evolving standards that had not yet been fully ratified (and for which, therefore, widespread support could not be guaranteed : e.g., HTML 5), nor basing our work on outdated technologies that would restrict our ability to present the work in the most effective manner. We also chose to eschew proprietary technologies such as Flash and Silverlight, not because of any prejudice or for political reasons but simply to maximise the probability that our project would display as intended on any modern computer running any modern operating system. We therefore decided to standardise on just five open standards :

1. Unicode (Version 6 or later, ISO/IEC 10646:2011)
2. The Hypertext Markup Language HTML (HTML 4.01 Strict)
3. Cascading stylesheets (CSS 2.1, with the exception of the "accordion" menu which exploits some features from CSS 3)
4. JavaScript/ECMAScript (ECMAscript 5).
5. The W3C Document Object Model ("DOM") : the glue that binds everything else together.

For those with a background in "Computing in the Humanities", it may seem strange that we have no underlying XML and/or TEI layer; this omission was made solely on pragmatic grounds — if we were to be sure of being able to deliver the project on schedule, we would need to use technologies with which all members of the research group were reasonably au fait, and in which our lead technical advisor had considerable existing expertise; had we elected to do otherwise, it would almost certainly have more than doubled the time to bring the project to completion, and may well have compromised the project's very chances of success.

Functional overview

When the Electronic Edition is first opened, it will be seen to be divided into two panes — on the left, an electronic facsimile of a single folio from the codex, and on the right the transcription of the folio. Above the facsimile of the folio are a [Home] button (clicking on which will take the user to the project "home" page) and a series of navigation aids : a direct text-entry field labelled "Folio : " and an accompanying [Go ! ] button, two buttons labelled [« Prev] and [Next »], between which is a drop-down menu through which the desired folio can be directly selected, and finally a button labelled [View MS]. Above the transcription are two drop-down menus through which the desired text ("Edition", "Transcription" or "Translation") and line-reflow (for the edition only) : "None", "Normal" and "Full" can be selected, and four further buttons labelled [Help], [Feedback]. [Home] and [Debug]. The function of each of these will be discussed below.

Simultaneous highlighting of MS facsimile and text

With the MS facsimile and transcription displayed, moving the mouse cursor over a word in either the facsimile or the transcription will result in the word under the cursor changing its colour to red; this colour change will take place both in the text and  in the image. The functionality is symmetric : it matters not whether the cursor is in the text pane or the image pane — the corresponding word in both text and image will turn red.

Lexicographical analyses and online lexica

When the cursor is in the text pane, additional functionality is provided — clicking on any word in the text will result in a full lexicographical analysis being displayed in the footnote area. For example, the opening word in f. 1r is "Τῇ", and clicking on this word will cause the text "Τῇ: Article, fem dat sg. form of ὁ (fem: ἡ; neut: τό).  Lemma: ἡ; see [Archimedes][Perseus] [TLG/LSJ] " to be displayed in the footnote area. The lexicographical analysis, while complete, cannot possibly say all that there is to be said concerning the word in question, and so links are provided from the analysis to three very important online lexica : The Archimedes Project, at Harvard; the Perseus Project, at Tufts; and the Liddell-Scott-Jones Greek-English Lexicon hosted by Thesaurus Linguae Graecae at the University of California, Irvine. If any of these links is followed, it does not  open a new browser window or new browser tab, nor does it overwrite the text and the lexicographical note; instead, it displays the relevant information in the space normally occupied by the MS facsimile. This has many benefits : it leaves the text and the lexicographical analysis visible at the same time as the contents of the external link, and the reader can (if he/she so choose) alternate between the off-site content and the MS facsimile simply by clicking on the lexicon link. It is not necessary to switch windows or tabs, nor even to use the browser's "forward" and "backward" buttons : the text remains in place, the lexicographical analysis likewise, and the user can view either MS facsimile or external text as he/she chooses. The MS facsimile can be restored by clicking on the "View MS " button at the top of the MS pane.

Apparatus criticus & apparatus fontium

If, instead of the transcription, the edition is selected in the text pane, then even more functionality is exposed. The simultaneous highlighting of words in the text and image functions as before, each word is still linked to a lexicographical analysis and so on, but in addition a number of scholarly apparatus  are now offered. Some words in the edition, for example, are picked out in green; these indicate a textual emendation that took place during the preparation of the edition, and hovering the mouse cursor over any one of these will pop up a "speech bubble" which contains details of the emendation and the reason(s) lying underlying it. For example, hovering over "ἐμφανεστατῃ" in f. 1r (Edition) will display the note "corr.: ἐμφανέστατῃ cod." in a speech bubble pointing to the word in question (the transcription contains "ἐμφανέστατῃ" at this point, of course, since it faithfully reflects the exact orthography of the author). The early folia contain only further apparatus criticus, but when f. 4r (Edition) is reached, an example of apparatus fontium can be seen; this takes the form of the superscripted number [1] following the italicised text "μῆλον ὑπερφυὲς μεγέθει", and if this number is clicked, the text "[1] Plutarch: Life of Artxerxes IV:5" (indicating the work to which the author was referring) appears in the footnote area. Clicking on the raised [1] a second time will dismiss the footnote text. This functionality is also present in the translation with identical effect.

Special features of the translation : simultaneous highlighting and the apparatus scholia

Turning finally to the translation, there is again a linkage between translation and facsimile image, but in this case the linkage is not (and cannot be) on a word-by-word basis. Instead, the translation has been carefully prepared so as to echo the macro structure of the MS text, and the linkage between translation and image is therefore on the basis of a short stretch of text (a phrase, clause, sentence, whatever) rather than on the basis of a single word. Hovering over any word in either text or image will cause an entire stretch of text to be highlit in red, and the corresponding stretch of text in the opposite pane will also be highlit. Furthermore, in addition to the apparatus criticus and apparatus fontium already mentioned, the translation also contains instances of apparatus scholia, the first of which may be seen in f. 9r (Translation). Here, following the text "and subdued the impregnable city of Boulogne and triumphantly overcame the ranks of many enemies." a superscripted [a] can be seen. Clicking on the [a] will disclose a fairly long note in the footnote area commencing "[a] Henry launched a major invasion of France in alliance with the Emperor Charles V in summer 1544", and this note provides a historical background to the MS text at that point.

Using the navigation aids

There are several different ways of moving between folia : simplest, and probably the most convenient, is to move forwards or backwards by one folio by clicking on the [« Prev] or [Next »] buttons as desired; alternatively, any folio in the codex can be selected by using the [Folio] drop-down menu and clicking on the folio of interest or by entering the desired folio number in the [Folio] text box. Over the text pane, the Edition, Transcription or Translation can be selected using the [Text] drop-down, and when the Edition is selected line-reflow can be modified using the [Reflow] drop-down : the possible values are "None" (in which case the line turns in the Edition are in 1:1 correspondence with those in the MS), "Normal" (in which case the text is re-flowed but solidi ("|") are introduced to indicate the position of the line-turns in the MS), and "Full" (which is similar to "Normal" but without the introduction of solidi).

If an error is spotted in the text (or indeed, if the user simply wishes to comment on it), feedback can be sent to the team by using the mouse to highlight the stretch of text in question and then clicking on the [Feedback] button; this will pre-populate a web form with the URL of the current page (including details of the selected folio, text and reflow options) and the user will then be invited to supply his/her contact details, offer feedback on the passage of interest, and finally submit the form.

If help is needed on using the Electronic Edition, this Help text can be brought up at any time by clicking on the [Help] button above the text pane. This will display the Help text as an overlay to the MS facsimile, and the facsimile can be restored either by clicking on the [Help] button a second time or by clicking on the [View MS] button above the MS pane. The [View MS] button is also used to dismiss the display of the online lexica that are linked from the lexicographical analyses.

Finally the [Home] button returns the browser to the landing page for the project whilst the [Debug] button will cause additional diagnostic information to be written to the console log file which may help the development team identify the cause of any problems reported (whilst the code has been tested in a number of current mainstream browsers, there is always the possibility that something unforeseen may occur, or that the user may have elected to use a browser that behaves differently to those in which testing took place).

Implementation Details

Much of the underlying implementation functions in exactly the same way as a "normal" web page, and no attempt is made to document here those aspects that not innovative in some way. We concentrate instead on those aspects of the implementation that, we believe, are both innovative and interesting, and these are presented in the order in which they (a) take place (as the page is loaded), and then (b) in the order in which it is anticipated that most users will exploit them.

1. The static code
   
   
   1. Syntax errors
      
      
      • Any syntax error detected by the JavaScript (hereinafter "JS") interpreter will result in a pop-up alert; the user is referred to the error console for additional diagnostic information
        
        
   2. Global declarations, naming and other conventions
      
      
      • In order to minimise the risk of an inadvertent reference to a global variable (e.g., because of a missing local declaration in a function), a single global object called "Global" is declared; all other global variables, no matter whether simple or structured, are declared as members of this single global object
        
        
      • Both constants and load-time variables are initialised at the point of declaration, and no naming convention is adopted to differentiate between the two, nor is the so-called "Hungarian notation" (oGlobal, strFolio, . . .) used, for philosophical reasons that we do not seek to justify here
        
        
      • Multi-word identifiers use case differentiation with a leading capital to identify word boundaries (ApparatusCriticus, LexicographicNotes, . . .)
        
        
      • Local variables are normally all lower-case unless (a) they are abbreviations (XHR, URL) or (b) are multi-word (see above)
        
        
      • The short form of array declarations (var linkage = [ ]) is used rather than the long (var linkage = new Array () )
        
        
      • ALL redundant semi-colons are deliberately omitted
        
        
      • Braces (and other paired delimiters) either occur on the same line or are vertically aligned; we do not pair an open-brace (or other delimiter) at the end of one line with the corresponding close brace at the start of another
        
        
      • In general, the code is written in a procedural manner; the use of object-oriented code is normally restricted to references to library objects
        
        
      • try {} catch {} is used where errors are anticipated; it is by no means impossible that errors may occur elsewhere and further try {} catch {} clauses may be introduced in later revisions of the code.
        
        
   3. Browser differences
      
      
      • As far as possible, all code is written to perform identically in the two main browser families (Gecko-based, IE-based) — in other words, code is written at the level of the highest common factor; where differences are known to exist and the HCF approach is untenable, variant code is used to handle these differences. For example, the [Go ! ] button exists solely because IE does not recognise <return> as indicating "confirm data entry" for a text field in a form element)
        
        
      • A null replacement is provided for "console.log ()" which will (for example) result in no console logging in IE unless the console log feature is enabled (via F12) before the page is loaded
        
        
2. Load-time initialisation
   
   
   1. The syntax-error handler is nominated
      
      
   2. The global object is declared, and its members declared and initialised
      
      
   3. A null replacement is provided for "console.log ()" if the latter does not exist
      
      
   4. A number of external files are loaded (apparatus criticus, apparatus fontium, apparatus referentium, betacode, lexicon, dictionarium) and global arrays are populated with the contents of these. Such files are loaded using XMLHttpRequest ()
      
      
   5. A null mouse handler is established, and hooks created that will allow this to be replaced with the real mouse handler once all necessary initialisation is complete
      
      
   6. A replacement is provided for "window.getComputedStyle ()", which is missing in early instances of IE
      
      
   7. The suite of JS modules associated with Sheldon McKay's popup balloon utilities is loaded; the reader is referred to the documentation associated therewith for details of their load-time behaviour
      
      
   8. At this point, load-time (static) initialisation is complete.
      
      
3. Run-time initialisation
   
   
   1. When the document has finished loading, the event handler associated with the "onLoad" attribute of the document's <BODY> element will be invoked. This is specified in the document's HTML as the function "OnLoad ()", the behaviour of which is as follows :
      
      
      1. Any parameters associated with the URL are retrieved and their values (or their default values) stored in the global object — these are passed as a structured query string, the syntax of which may be easily deduced from the following example :
         
         
         • ?folio=f001v;text=Transcription;reflow=None;debug=False
           
           
      2. Using the values retrieved or defaulted from these parameters, the desired folio, text and reflow are selected; as a side-effect of selecting these, the associated map (q.v.) is retrieved and analysed and the associated mask (also q.v.) selected
         
         
      3. Handlers for all anticipated mouse events are prepared and stored in the global object
         
         
      4. In a single monolithic operation (so as to avoid any possibility of a rafe hazard), all dummy mouse handlers are replaced by their active equivalents
         
         
      5. At this point, all initialisation is complete, and all further behaviour result directly from user interaction; however, a great deal of background work was carried out during run-time initialisation (particularly under ii., above) and it is necessary to explain this in far greater detail before the behviour resulting from user interaction can be properly understood
         
         
   2. Under ii, above, it was stated that "the desired folio, text and reflow are selected [using the values retrieved or defaulted from the parameters]; as a side-effect of selecting these, the associated map (q.v.) is retrieved and analysed and the associated masks (also q.v.) selected". This, it turns out, is a very superficial analysis of what takes place, and the actual steps involved are both many and complex : they will therefore be covered in considerable detail.
      
      
      1. Selecting the desired folio
         
         
         1. from the "folio=f001v"-type information present or defaulted in the URL parameter string, and from a number of intrinsic and/or computed constants, the code is able to infer that the required folio image is "Royal_MS_16_C_X_ f001v.jpg" and that that this is to be retrieved from a directory the location of which can be computed from the URL of the current document (i.e., the path to the image is a relative URL).
            
            
         2. If the image is loaded successfully, an attempt is next made to load the map file associated with the image (such files consist of a large number of <AREA> elements, each of which defines one rectangular sub-region of the folio image : in an ideal world, there would be exactly one <AREA> element for each word in the manuscript, but life is rarely that simple and in practice words frequently have to be broken down into a number of (possibly overlapping) sub-areas, for reasons that will be explained later). The map files must be prepared by hand — a vital but labour-intensive task.
            
            
         3. If the map file is successfully loaded, it must next be analysed. For each <AREA> element in the file, there are two key attributes : "coords", which specifies the co-ordinates of the (rectangular) region defined by that particular area, and "class", which would normally be used to denote the CSS class(es) with which it is associated and thus the CSS style(s) to be applied to the element; however, as maps are invisible they have no need of styling, and the "class" attribute is in fact used as a convenient way of passing information to the analyser. In particular, each "class" attribute will be of the form "class='Rr Ll Ww'", where "R", "L" and "W" are the actual characters but "r", "l" and "w" are integers denoting the region (r), line (l) and word (w) of the word with which the area is associated (e.g., "class='R1 L2 W1'"). It is through this mechanism that it is possible to unambiguously associate multiple areas with one word : i.e., for all areas associated with a given word, the class values will be identical. The line and word values will be used to associate a particular word in the folio image with the corresponding word in the text (i.e., in the transcription or the edition)m but as the concept of "the corresponding word" is not meaningful for the translation, the mapping there is at a coarser level of granularity which is referred to as a "region", whence the need for an "R"-value in the class. Since the analysis is time-consuming and is therefore performed only once for each folio for reasons of efficiency, the global object is used to all of the co-ordinate 4-tuples associated with each region, and with each (attested) combination of line and word. The maximum number of areas associated with any single word is also recorded; this will later be used to determine how many instances of each mask (q.v.,) will be needed.
            
            Whilst analysing each <AREA> for co-ordinates and class, the opportunity is taken to associate a unique "id" attribute with each : the attribute value is formed by interpolating appropriate values into the string "FO-Rr-Ll-Ww-Pp" (for "r", "l" and "w" as previously defined, and where "p" represents the particular part of the word with which this area is associated (i.e., p = 1, 2, 3, . . .) — this unique ID would normally be used to facilitate direct access to the element (using getElementById () ), but here it is primarily used to provide a many:1 mapping between areas of the folio and words in the text. Just as each area in the folio map has an ID of the form "FO-Rr-Ll-Ww-Pp", so each word in the text has an ID of the form "ED-Rr-Ll-Ww" (for the Edition) or "TC-Rr-Ll-Ww" (for the Transcription) : it is thus very simple to identify which areas in the map correspond with which words in the text, a feature of which considerable use is made. The opportunity is also taken to bind two event handlers to the area — these will deal with possible 'onmouseover' and 'onmouseout' events, and will in practice result in the simultaneous highlighting of a word (or region) in the folio and the text when the mouse is moved over the word (or region) in the folio; detailed discussion of these will be deferred until later.
            
            
         4. When analysis of the map is complete, the program next attempts to locate and load the mask associated with the folio image. Before going into the details of how this is accomplished, an explanation of the nature and rôle of a mask must be given :
            
            Each folio image is similar to a greyscale scan of one particular folio of the MS, but whereas conventional greyscale images consist of nothing but shades of gray, our "greyscales" consist of shades of sepia; in use, when the mouse is moved over any word in the folio image, that word is highlit by displaying it not in shades of sepia but rather in shades of red. Whilst it would in theory be possible to carry out real-time image manipulation to achieve this effect, it would be extremely resource-consuming and a decision was therefore taken to pre-process all folio images in the collection. The set of masks therefore consists a set of images which are identical to the folio image collection except that every possible shade of sepia in the original is replaced by the corresponding shade of red in the mask. If the program were displaying the folio image for (say) f001r, and this were suddenly replaced by the mask for f001r, the user would notice no difference other than that it had apparently changed colour from sepia to red.
            
            The actual mechanics of locating and loading the mask image corresponding to a folio image are trivial, and are accomplished by nothing more complex than simply re-writing a part of the URL for the folio image and then loading the corresponding mask using XMLHttpRequest () specifying the modified URL. What follows, how ever, is far more complex and important —
            
            It was mentioned above that, when analysing a map, a note is made of the maximum number of areas associated with any given word. This number, referred to in the code as 'Global.MaxParts', is now used to load not one but n instances of the mask, where n = Global.MaxParts. Because browser implementations are highly optimised, this does not require n fetches of the mask from the server : in practice, not only is the mask cached after the first fetch, but even more beneficially images are embedded not by value but by reference, so in fact only one instance of the mask is fetched and stored. But logically there are n instances of the mask, and each of these is associated with a different layer — HTML allows a web page to consist of multiple layers which can (if desired) overlap, either partially or fully. Where two or more layers overlap, only the topmost layer is visible, unless it is transparent, in which case the next layer beneath is visible, and so on.
            
            So now all of the elements that will be need to highlight a single word in the folio image are in place : the image itself; a sufficient number of masks, all identical to the image except for their colour (they are red, the image is sepia); a map that partitions each word into a number of (possibly overlapping) rectangular areasand a record of how many such areas are associated with each word, and the co-ordinates of each. The highlighting process (which will be returned to in the section devoted to the response to mouse activity) will therefore be as follows :
            
            The initial state of all mask layers is with visibility: invisible and the clipping region set to a zero-area rectangle with co-ordinates (0, 0, 0, 0). The code iterates through the set of areas associated with the word of interest and with each associates a mask layer. The co-ordinates of the area are retrieved, and these are then used to define the rectangular clipping region of the associated mask layer. And finally the visibility of the layer is set to "visible". Thus a second copy is built up of the word of interest, identical save for its colour, and consisting of a number of layers each of which is clipped to display exactly one rectangular part of the word. As each of these layers is logically "on top" of the layer containing the sepia folio image, the rectangular region to which each is clipped obscures the corresponding part of the sepia image, and thus what remains visible is a sepia image of the folio with a single word displayed in red. The technique is generalised when the translation is visible in the text pane, as then a whole stretch of text is highliit rather than a single word, but the underlying methodology and technology are identical. It may be worth noting in passing that, as the rectangular areas can overlap and only the topmost part of any overlap can be visible, it might be thought that this could result in a part of the word being hidden, if it occurs only in an intermediate layer : in practice this will never be the case, as the content of all overlapping parts is identical — thus it does not matter if a part of an intermediate layer is obscured, as its content will be replicated in the corresponding part of all higher layers (and also of all lower layers, but this latter fact is irreievant and is noted only in the interests of precision). "De-highlighting" a word (which occurs when the mouse leaves its vicinity) is simply the reverse of the above : the clipping region of each layer is reset to (0, 0, 0, 0) and its visibility reset to 'invisible'.
            
            
      2. Selecting the desired text
         
         
         1. Using once again XMLHttpRequest and the code's intrinsic knowledge of how to compute the URL at which the required document is to be found, the text corresponding to the current folio is loaded. Each text exists in three versions : transcription (near-diplomatic), edition, and translation, but only one of these is ever loaded at one time. As considerable work will be carried out on the DOM representation of the text once it has been loaded, a number of global variables are initialised preparatory to this task. And, as it is possible that the previously displayed text (if any) had been interrogated for data from its apparatus criticus, fontium, or scholia, any previously displayed annotations are concealed. If the text is an edition, then its reflow characteristics (which affect how line-endings in the folio are presented in the text) are set to those requested. Once that has been done, a great deal of behind-the-scenes activity takes place through a mechanism known as "walking the DOM".
            
            
         2. "Walking the DOM" is web jargon to describe an activity that is pivotal to not only this project but to many others besides. It is necessary to start by explaining exactly what the DOM is, how it is created, and the rôle that it plays when a web page is rendered. The DOM ("Document Object Model") is the internal representation of a web page, created when that page is loaded and capable of being subsequently modified (without any impact on the source document) by scripting languages such as JavaScript and even by events such as a mouse gesture ora key press. Although one tends to think of a web page (i.e., an HTML document) as being rendered, in practice this is no longer the case (and perhaps never was) : instead, the web page is parsed, a Document Object Model built in the computer's memory, and then that DOM itself is used to generate the rendered image.
            
            
         3. In the context of the current project, "Walking the DOM" is used to analyse the content of the text page associated the current folio. Such content (for a transcription) will typically be along the lines of the following :
            
            

                <P>
                    <B class="L1 W1" >Τῇ</B> 
                    <B class="L1 W2">τιμιωτάτῃ</B> 
                    <B class="L1 W3">κ(αὶ)</B> 
                    <B class="L1 W4">ἐμφανέστατῃ</B>
                </P>

            Each <P> element contains a single line of the folio, and each <B> element contains a single word of that line. The "class" attribute is used to indicate explicitly indicate the line and word. This is near-minimal markup ("near", in the sense that it might have been possible to avoid even the need for the "class" attribute, but these were introduced early in the development cycle and there seemed little point in removing them once the DOM-walking code was in place), and it will be obvious that there are, for example, no event handlers associated with each <B> element. These, and other essential attributes, will be grafted on to each <B> element as the DOM is walked.
            
            Because all well-formed HTML documents can be viewed as serialisations of a (mathematical) tree, "walking the DOM" is in fact a recursive process. Starting at the root element, which for one of the text documents in this project will be a <DIV>, the code ascertains whether or not this element has any child nodes; if it does, then the sub-branch of the DOM rooted at that node is walked, and so on. Whenever a node is reached that has no descendants, any additional operations are necessary are performed and then the code returns to whatever it was doing prior to walking that node. The tree-like nature of the DOM ensures that this process terminates (the same would not be true for a graph).
            
            As each <B> ("word") node in the DOM is walked, the code retrieves the line and word associated with that node and from its intrinsic knowledge as to whether the current text is an edition, transcription or translation, a unique ID is then grafted on to each node to facilitate its rapid access using getElementById (). For an Edition, such IDs will be of the form "ED-Rr-Ll-Ww", for a Transcription "TC-Rr-Ll-Ww", and for a Translation "TL-Rr-Ll-Ww" (and all will, of course, be unique : it would be both a logical error and a violation of the rules governing the structure of the DOM if any two were the same).
            
            In addition to grafting on a unique ID, we also graft on a number of event handlers. The "onclick" event, for example, is bound to a handler that will display the lexicographic information associated with the word that forms the content of that node; as it is possible that two or more words might be visually indistinguishable (i.e., spelled identically) yet actually be different parts of speec, provision is also made to pick up additional data from any "content" attribute associated with the node, and this data is then used by the event handler to retrieve the exact lexicographic information associated with that particular combination of word and part of speech. The "onmouseover" and "onmouseout" events are bound to handlers that will highlight the word both in the text and in the folio.
            
            In addition to <B> elements, which denote words, the texts also contain <SPAN>s; these are used to provide an association between a particular stretch of text and an entry in one of the four classes of apparatus : criticus, fontium, referentium and scholia. When a <SPAN> element is encountered during the DOM-walk, the value of the "class" attribute (if any) of the element is retrieved, and from this is determined to which of the four possible apparatus the <SPAN> is linked. Once this is know, an additional "trigger" element may be grafted into the DOM, if the contents of the apparatus are to be displayed only as a result of a mouse-click (the trigger element will typically be rendered as a superscript on which the user can click to disclose the contents of the relevant apparatus entry). Not all apparatus entries require a click in order to display them, and for those that do not, no additional trigger element will be necessary : instead, simply hovering over the word or stretch of text in question will be sufficient to reveal the entry, and this will take the form of a "speech bubble" adjacent to the text under the mouse.
            
            Apart from <B> elements and <SPAN> elements, only one other type of element is afforded special treatment during the walking of the DOM, and that is the <DIV> element. Its normal role in the texts is to act as a container for the whole page (i.e., the root element, from which DOM traversal will start) but it has an additional role in relation to the apparatus scholia (i.e., a commentary on a particular historical event). Because the large number of, and generally terse nature of, the entries in the other three apparatus (criticus, fontium, referentium), they are each stored in a single file (i.e., three files in total). However, apparatus scholia entries are both few and generally discursive, and it therefore makes more sense to store them in the page from which they are referenced. Thus when such a page contains one or more apparatus scholia entries, each of these will be contained in a separate <DIV> element, and the DOM walker will extract the contents of each of these and store it in the global 2-dimensional array "Global.ApparatusScholia [ ] [ ]" from which it can be retrieved when the user indicates (by a mouse gesture) that it is to be displayed.
            
            
      3. Selecting the desired reflow
         
         
         1. As has already been discussed, whilst the presentation of the transcription and translation are fixed, the style of presentation of the edition is under user control. As, by definition, an edition can only coincidentally be in 1:1 correspondence with the text from which it is derived, it is necessary to decide how line-turns in the original text will be indicated in the edition. In the present project, three options are offered, and are under user control :
            1. Reflow: none
            • Line turns in the folio are the same as those in the edition
            2. Reflow: normal
               • Line turns in the folio are indicated by spaced solidi in the edition
            3. Reflow: full
               • Line turns in the folio do not appear at all in the edition, and the latter can therefore be read as a stretch of uninterrupted prose.
         2. The implemention of this is extremely straightforward. If the desired reflow has been passed as a parameter to the URL, that value is used; if not, the current value of the "Reflow" dropdown is used instead. Using getDocumentById (), (to be continued . . .)

Philip Taylor