Internet Editions of Shakespeare
Discussion Page

Also from this page you can access two recent articles by Michael Best on

• issues of display and
• copyright for the Internet Editions.

I have only had time to take a quick peek at your R&J pages and bookmark them so I can come back later today and really burrow in.

The first thing that struck me is that instead of using the (N) thing at the end of a line, why not let HTML do what it does best--just underline the words you're annotating. You can tell the file what color to make the links, so if you told it to make them the same color as the text, then it wouldn't be distracting. Of course, that leaves the links at the top and bottom not very visible, but I think it's the eftest way. The end (N) rapidly become an distraction.

------------------------------ My reply:

You are probably right. I put the [N] there for two reasons: it makes the text less interrupted, and it allows a distinction between [N]otes and [T]extual comments -- but in the medium of the Internet the underlined and coloured link is the norm, so perhaps my solution is actually more distracting. I'll try both for starters and see which works best.

[I have since followed his suggestion, as the current pages attest.]

One idea re performance I have is a listing of ALL, and I mean ALL the speeches and monologues in Shakespeare, by Gender, play, "style", etc. with links to the text. Could this be part of your site? I think it would be extremely helpful to actors, professionals as well as students.

Coming from the text-analysis end of things, I think of *finding* the numbers of a text rather than imposing them. For that reason, the more items I can find to number, the better. Why decide against putting in some numbers and not others? Even worse, why add a numbering system that's not in any of the originals? doesn't that muddy the waters?

If you decide to end a line of prose at a place different from the folio, or Q1, or Q2, you are not necessarily imposing a lineation because the line number can still appear -- in the middle of the line, or not on that line at all! It doesn't need to go on the right. The question of putting in carriage return/linefeeds is different from deciding on a numbering system. I still favour using a numeration that has the authority of one of the original texts. On balance, TLN makes best sense to me as long as it derives (as I believe it does) from one authoritative text.

By splitting numeration from layout, you solve the problem. The browser can impose the line length that best meets the needs of the display. You are not compromised. The moment you put in one <Enter> without having an earlier, authoritative text in mind, you're unnecessarily standing between the reader/user and the best texts, aren't you?

For one thing, aren't you saying, "this here is prose, not verse" (because you believe you have the right to split the text here)? --------------------------------- My reply:

I should have explained that my questions were directed towards the HTML versions of the texts rather than SGML.

Indeed, it will be possible and desirable to provide multiple ways of numbering the SGML texts, and of searching the HTML versions. But I still feel that browsers used to the emerging style of Web pages will want some system of line numbering that is visible, although at present HTML offers no elegant way of right-aligning numbers. And they will want to access the "pages" conveniently while on-line. The opportunity is thus less to "impose" a numbering than to discover the most elegant way of defining numbering in the new medium -- while of course retaining choices where possible. As you point out, no such numbering will be authoritative, but no numbering has ever been authoritative, and that's not what I'm looking for anyway. It seems to me that it would be odd, to say the least, in an article that used the electronic editions to give a citation through a Riverside number.

So I'm still thinking about it, and beginning to favour the view that in HTML a line is a line is a line: a verse line, or a prose line, defined by the equivalent of a carriage return in a word processor, the <br> or <p> element in HTML.

>The nice thing about electronic editions is that you're completely
>free of the need to impose layout.

Ah, but in HTML you can't avoid it to some extent. And even in SGML you will be making decisions about what is prose, what verse -- and what is that if not "layout"? As usual, borders are fuzzy.

>So my question for you is, why do you think you need to have a
>special lineation and pagination of your own?

See above. Pages are still an issue in HTML for the simple reason of the convenience / inconvenience of downloading. At present I am thinking of a choice between "scene" pages (ideal for permanent downloading) and shorter chunks as in the current pages of _Romeo and Juliet_ (for browsing). But each different version in HTML requires inserting different links, so the number of choices will be limited.

What about the system used for classical (i.e., Greek and Latin) texts, where the sentence and paragraph are the designated units? Those are meant to be independent of format. I can anticipate a problem with punctuation, but one might adopt a consistent standard, such as the Folio text, as a basis. --------------------------------- My reply:

This is an interesting idea. I forsee problems in verse, however, since some sentences are inordinately long. It might be a useful way of breaking up long prose passages, which at present will be represented by one line number. And the Folio as a base is sort of ok, except where some other text is the copyt text (and has passages not present in the Folio). But I'll add your comment to the discussion. Thanks.

Why does an electronic edition need line numbers?

"For citation," you will say. Let's examine that need. Unless bandwidth can somehow expand much more rapidly than the internet acquires new users, scenes are probably the sensible way to 'package' an online edition of a play. Since in each scene we have at most a few hundred lines, a user would be able to locate any single line (or part) by using the 'find' function of hir browser. We don't need a number to find a location in the text.

Line numbers seem to be an artifact of book culture, determined originally by format and production exigencies such as page size and the compositor's variable accuracy in casting off copy when composing by formes. Although the desirability of line numbers is strongly reinforced by the citation conventions of academic publishing, we're slowly working our way through that problem (not very successfully so far, because no standard of web site design exists).

In an electronic environment where "page" is an irrelevant idea, maybe abandoning the line number is worth thinking about. The sheer vexation the problem creates implies that trying to keep line numbers is to persist in thinking of the electronic environment as a mirror of the printed one. The medium itself strongly resists line numbers.

I recall how early printed books imitated manuscript books because the first printers had no other idea of what a book could look/be like. Is trying to keep line numbers in an electronic edition falling into the same trap? --------------------------------- My reply:

In essence I agree.

I just thought that perhaps the use of frames would help the ease of reading of the text. Perhaps when the reader follows a link to a reference, a frame containing the note would appear at the bottom of the page. The reader would then be able to have both the text and the note on screen at the same time, thus eliminating the need to use the "back" button to return to reading.

I hope this comment is useful to you and your project. --------------------------------- My reply:

Thanks for the comment. In general I detest frames -- they clutter up the screen and serve no real purpose -- but your option is one that will in due course be considered. Eventually (when there are real texts there!) I expect the user to be able to choose a variety of formats, of which one could well be framed footnoting.

There are also browsers that support multiple windows -- in many ways a better solution, I think, since text is most comfortably read in shorter lines (as verse, for example) than the full width of the screen.

One thing you seem to neglect in your thoughts on notes and the text is the possibility of more than one window being open. This will allow notes to be in one window and the text to be in another. In that way the text would be able to scroll easily in one window (without reloading) while reading notes in another. This sounds very complicated but it is certainly do-able. "Frames" might also permit you to have the text in a narrow window with notes appearing below or to the right.

I am in favour (if you could institute some of the above) of a scene breakdown, rather than a "page" breakdown. --------------------------------- My reply:

Another reader made a similar comment (see above). I have indeed thought about it, and clearly should include it in the general discussion. It's a strong argument for having notes or collations in separate files rather than within the basic file.

About frames I'm less sure. So far they seem to me to constrict the viewer's options rather than making things easier -- but I'm of course open to all kinds of possibilities as the texts come on line. Since the basic materials will be tagged in a consistent and generalized format (SGML) it will be possible to offer different "filters" to display them differently as the technology improves, without doing any rewriting of the texts themselves.

On pages and scenes, I've come around to your position as well, though there is a huge variety of size involved. Internet readers are more likely to want to download chunks to look at on their own machines rather than browse on the site itself for long periods, and the division by scene lends itself more to that way of dealing with the texts.

[Return to top]