Finally, an example from my own experience looks as if it might inform the way Player King is put together…
This morning, a pretty plausible, very short piece of dialogue between two characters came into my head: the characters were from a not-very-rom not-very-com screenplay I started some years ago, called Love and the Other, but in fact – given my propensity for writing not-very-rom not-very-coms – it could have come from two or three of my other ‘works in progress’. Indeed, it could have come from the same piece, but from different characters. The point is that playwrights often come up with self-standing bits of verbal business – epigrams, cross-talk, put-downs – whose position within the larger text is flexible. So Player King should offer the possibility of adding these very quickly and outside the main body of the text, and not only that, but should allow them to be easily moved around even after they have been placed within the text, if the playwright feels that they would work better elsewhere. This suggests that they need either their own element (along the lines of standalone, perhaps?) or an attribute value for a fairly standard structural element (eg section standalone=”yes”, or words to that effect). The interface could then treat them differently from the other pieces of text, based on the recognition of that special element/attribute. (I’m assuming an interface could be made to do this: indeed, practically everything I’m considering for Player King – the characters, the structural elements like acts and scenes, the directions – depends on this facility…)
|[xml categories]||2.32 pm|
Having been editing and setting a large project, originally written by its authors in Microsoft Word and opened by me in OpenOffice (via the rather slow – but very free! – Mac interface NeoOffice), I’ve become a bit more conversant with how word processors deal with xml.
I saved one of the chapters (which arrived with me as a ‘.doc’) in the standard format for OpenOffice, (with the extension ‘.odt’), which is apparently a ‘zipped’ folder of files. This can then be opened with an application like StuffIt Expander to reveal the folder and its constituent files. The key file is called ‘content.xml’, where the original text is held. As the Word document I received in this case was marked up on a line by line basis – a headline, for instance, made bold, centred and increased in size – rather than via Word’s stylesheets, the differing formats were given consecutive attribute name values: eg, ‘P1’ for formatting covering a whole paragraph, ‘T1’ for changed formatting within a paragraph.
This file is very difficult to read as text, even in BBEdit, which helpfully assigns different colours to the various parts (instructions, comments, elements, attributes, etc) of an xml document. Fortunately, I also have the ‘domestic’ (ie free) version of an application called ‘XML Editor’, which lays the document out as a series of forking paths (or a family tree on its side), so it becomes much easier to work out what’s going on. It turns out that there are no less than 23 paragraph alternatives listed, many of which are there because of a slip of the keyboard or mouse. There are even more alternatives for text (25 or so), largely I suppose because there are different ways one can alter text: font, size, style.
As an experiment I’ve also created a small file with styles all present and correct. This uses the names of the styles used in the word-processed document as name attribute values rather than as elements, and keeps the element distinctions (eg ‘text:p’, ‘text:list-item’, ‘text:span’) relatively simple. I imagine this would not be so difficult to change to something more meaningful (and more in the spirit of xml) via xslt. The ‘unstyled’ version, on the other hand, looks like a nightmare to do.
Since I started researching this subject, there’s been some attempt by Microsoft to incorporate xml into their export options for Word. Naturally enough, they refuse to use the same variant of xml that is currently used by OpenOffice – where would be the fun in that? – and have come up with one of their own, which I gather will appear in the next version of Microsoft Office. It’s almost certainly going to be along the same sort of lines as the OpenOffice version. It would be nice to think that once this is in place, enterprising people would come along and provide ways of turning these not-terribly-useful files into more straightforward xml and xslfo documents. But the intelligent ‘style recognition’ application or plug-in I mentioned in my previous entry would surely be a better route.
|[General remarks]||1.41 pm|
Yesterday’s editing and typesetting work on a new play (someone else’s, of course) has reminded me of a huge issue that I’ve failed to cover in previous ramblings about this ‘Player King’ idea: importing already-written scripts into the new system.
Most of these will be in Word, and even those that aren’t (in Final Draft, say) are usually exported in that rather grisly format rtf. There are a couple of commercial versions of rtf to xml converters: the ones I’ve tried in the past are UpCast and R2Net, though I’ve never thought enough of either of them to go the final step and actually buy them. (When I had to do the conversion for real, at my last job but one, I used a free French program which was, even then, more or less obsolete – and, I suspect, was never really finished – but was nonetheless pretty sufficient for my purposes.) One of the main problems, I would have thought, is that the Word user, encouraged by the ever-eager-to-please nature of the program, will produce a document that has little logical structure: there may be some attempts to create new styles for particular parts of the text, but more often than not you’ll just get a local variant of the default styles ‘Normal’ and ‘Default paragraph text’. Converters that rely on the principle of mapping Word stylesheets to xml elements may not get very far. I’ve recently read descriptions of a couple of programs whose basic assumption seems to be that the user just wants to have a new version of the document that somehow incorporates xml: the conversion produces an xml file with the textual information and an xsl-fo file for all the formatting. But if the user has made their heading by enlarging, centring and emboldening a line of ‘Normal’-style text, then how will the xml file register this fact? Will it use a
The best solution, I would have thought, would be to prepare the rtf document in advance, using some form of ‘format recognition’ to ask the user whether to convert parts of the text set out in a particular way to certain stylesheets, and then do a stylesheet-to-element match when converting into xml. In the case of a play script, there may be all sorts of horrors – for instance, many users never get the hang of hanging indents, so break the text manually at the end of a given line and then put tabs in to where they want the indent to be, before starting the text again – but in some senses it might be easier to work with: there would, after all, be a specific (and relatively short) series of elements to match the text to, and the regularity of much of the text (eg a speech is clearly evident from the capitalised/emboldened word followed by a colon or tab; a paragraph of directions may be in italics and/or in brackets) would help a ‘recognition’ plug-in or standalone application to make many of the correct decisions automatically. NB It might be worth considering how a user interface for this preparatory software would look.
|[General remarks]||1.37 am|
I’ve recently downloaded a piece of writing software called Glass Pro. Its author is a novelist in his spare time, and came up with it to help him actually finish writing his books. It appears to have been rather successful in this endeavour, though obviously I have no idea whether the novels thus completed are any good or not. But because it was specifically for writing a particular literary form – when you launch it, it immediately takes you to a page with the words ‘Chapter 1’ at the top – it did seem analogous to what I hope for Player King. And it, and some plays that I’ve been sent to edit/look at, made me wonder about what a playwright might want in the way of a standard user interface.
In my experience, writers of drama are rather impatient, both to get the poignant observations and one-liners down on the page, and to have it look properly like a play. They might well rebel against the strict layout that an xml-based application might logically offer. My thinking was that they should be offered a variety of possible interfaces, but that it should also be clear that there is a separation between what they are writing and how it might look. In other words, there would be a user-defined ‘input’ interface, and another ‘output’ interface – something of a violation of the WYSIWYG principle.
There needs to be a fair amount of flexibility with both of these interfaces. For instance, while I’m happy writing in black on a white background, a friend of mine prefers to write in white on a dark blue background. It might be worth the user being able to decide how many of the elements to distinguish, and in what way, when working on the text: some might prefer just to have things like italics shown, while others might prefer character names, directions and other parts of the text highlighted in some way. Still another possibility would be a tabular appearance, where the left-hand ‘column’ has the character name, the middle dialogue and the right directions.
Another key element with input would be way of navigating around very easily and, to a lesser extent, statistical information. (Glass Pro makes much of the latter, prominently displaying the current wordcount.) You want to be able to see what a particular character has said, isolated from the others (either within the full text, shown in a different colour or type style, or as a series of speeches or paragraphs);* you might also want to know how often a character speaks, or whether there is enough time for a costume change, or whatever.
The ‘output’ referred to is different – in concept, if not perhaps in practice – from what one might call the ‘export’ options: this is more like a proof. The user might want to print out a draft copy to send to someone, or produce one that they can look through at their leisure (say in a large type size and with more leading and marginal spacing than usual): these options should be customisable.
* Strictly speaking, these are ‘output’ interfaces, but then isn’t everything you can see on a computer ‘output’ of some kind?
|[User interface]||12.36 pm|
I’m still looking into ways of outputting the playscript as a pdf using TeX. The InDesign option (using the xml import) is pretty good, and straightforward enough, but there are many limitations, and you of course have to do a fair amount of extra work once in InDesign. There’s been an option in place for the past five or so years, which is supposed to allow you to produce pdf directly from xml using the xsl ‘formatting options’ (fo), a terrifyingly detailed compendium of typographic possibilities. There is a program called FOP (written, I think, in a language called Python) which uses xsl-fo to produce pdfs from xml files, but I must say I wonder whether this can really work properly, given the sheer difficulty programmers have had with getting typesetting engines right over the years. TeX doesn’t have that problem, and is still regarded – almost 30 years after it was created – as probably the best typesetter around (if only it was easier to use). Its collaboration with xml is troubled by a quite different view of how to use white space (leading to all sorts of troubles with spaces after italics, etc), but is fairly obvious, given that both systems use ASCII text and are free… At least one major publisher – CUP – produces many of its books this way.
There’s a version of TeX called ConTeXt, developed by some Dutchmen some years ago, which seems to be gaining on the old favourite LaTeX. In essence, this (like LaTeX) is a series of pre-defined commands for plain TeX which give the user a variety of common formatting options in a more accessible form. Yesterday I finally printed out the manual for this (like almost everything to do with TeX, this system is free and its documentation is largely available as pdfs), and must say I’m fairly impressed. I can even envisage creating a whole book in this format, which I could never do with LaTeX.
One problem with it, though, is the usual TeX issue with fonts. TeX by default uses its creator Donald Knuth’s own ‘Computer Modern’ fonts – created with his rather marvellous-looking but little-known MetaFont system – and has been fairly resistant to using anything else for a long time: ConTeXt, LaTeX and the GUI word-processing system LyX all have trouble with making use of the fonts one has on the system. A recent development, however, has been XeTeX, which let the user do exactly that without any of the tfm-creating, folder-placing nonsense that the other versions need. I’ve not been able to combine XeTeX and ConTeXt yet, but I might master that eventually. (I was knee-deep in Terminal commands trying to sort it out yesterday, which wasn’t somewhere I wanted to be.)
Of course, if the idea is to provide a user-friendly front-end for the xml and xslt stages of the job, then it might make sense to do the same for the TeX stage – and if that’s the case, then there wouldn’t be any need for an ‘easier’ way to manipulate TeX, because that would all be done behind the scenes. But I think as I begin to get familiar with these different systems, it would probably be worth sticking with ConTeXt – at least for now.
When originally I thought about what a playwright might want from a writing application, one obvious thing was a way of keeping and accessing drafts. I have no idea at all about the practical means of including this in the application, but I suppose I can think about it out loud.
Working from my own, not terribly extensive experience of writing scripts, I have occasionally changed the structure of a play quite radically, only to realise that it was better the way it was and try to change it back, having to remember what was originally where. So you’d probably want something that took note of differences on both a macro and micro level: structural and individual changes, in other words. It would seem impractical to let the writer be able to go through absolutely every alteration made during the course of a document’s existence, but it may be possible to do a summary of changes at the end of a particular session. Whether there would be the option to prompt the writer to save the document as a new draft is another matter.* Besides, do we want the drafts to be different versions of the documents, or use xml to keep the various drafts in the same document? In terms of getting user-friendly analyses of the changes, it might be better to have it all in one place, with some kind of draft element (although I dare say this could be handled just as well by a general, self-sufficient block of data within the ‘metadata’ part of each draft file, and if necessary a series of elements relating to the changes throughout the document).
There are a number of ‘file difference’ facilities in word processors and text editors (I know BBEdit has one, though I’ve never used it), and even some standalone programs (eg, see http://alphaomega.software.free.fr/differencesexaminer/Differences%20Examiner.html). It might be worth seeing how these work, but I assume, as usual, that xml would allow an extra sophistication to examining the differences. In particular, one would want to be able to choose what sort of difference to look at: changed text, differences to particular characters, moving scenes and acts about, and so on.
* This prompt struck me as a nice possibility – and presumably as straightforward as anything else to do with this – if it could be automatic (albeit subject to user preference) when a particular number of changes had been made to the document.
|[User interface]||Reference: strangerlove||3.22 am|
I’ve been experimenting recently with a test xml file in BBEdit. In fact, I’ve been writing dialogue, stage directions, etc, for an actual project – the new book of an old musical – more or less from scratch. In conjunction with this, I came up with a simple AppleScript that allows you to specify the name of new elements, then saves it into a new BBEdit glossary, which you can then access within BBEdit to speed up the entry of elements (and, incidentally, avoid easy-to-do typos when closing tags).
So productive has this proved, indeed, that I’ve already run out of inspiration where the text is concerned, so have turned back to the nature of the xml itself. The structure is fairly straightforward: the root element is, slightly arbitrarily, playbook, which has two ‘children’, details and play. The former is really for ‘metadata’: title, author, author’s agent, that sort of thing. The latter, as the name suggests, contains the play itself. (There is obviously room for preliminary text of some kind, though – as with more specifically publishing-related information, such as an ISBN – this is perhaps more suitable for when the play is turned into a book, when this whole document (the xml declaration aside) can be subsumed within another set of elements. All of which rather suggests that ‘playbook’ is a poor name for the root element…)
Within play, then, there is an element called section1, which accords with a conventional play’s ‘Act’, and within that, section2 (‘Scene’). A good thing about xslt is that these do not have to be numbered at the xml stage: you can use the count attribute of the xsl:number element to do this. In other words, you can change round the order of the scenes and even the acts in the original file without having to worry about getting the numbering awry.* Of course, there is something illogical about using a term like section2 if you’re not using section1 first – after all, plenty of plays have scenes but no acts – and I had hoped that I could call both section elements by the same name (ie, section) and distinguish between them at a later date, but this has so far proved impossible – for me, at any rate. It might be feasible to do this by using different attributes: and if these attributes were descriptive, eg act, scene, they might be also used to generate the text that comes before the section number. I will have to work on this.
The individual blocks of action/dialogue are found within the direction or speech elements. The second of these is the more complex: currently it divides into a character name (about which more later) and the dialogue element, which currently has sporadic outbreaks of emphasis (italicised text, more or less) and direction itself: because you specify xsl transformations by paths, I’ve been able to treat this ‘inline’ version of direction differently from the ‘block’ version above, even though they’re the same element.
The direction element is also able to contain references to the character names, which is where it all starts getting a bit interesting. At the moment the characters are supplied via an entity reference – handy, one would imagine, if the author hadn’t thought of the names yet. The entity currently consists of an outer character element, with the merest basics inside: name and sex. As I suggested in an earlier entry, I thinking in terms of a fairly comprehensive series of ‘fields’ (to switch to database terminology for a moment) for the characters: different versions of their names (full name, the version of it used before dialogue and within descriptions, what other characters call them), brief descriptions of what they do and/or where they come from), which are then accessed during the transformation process according to the context. One related embellishment is in the area of pronouns: I’m currently toying with the idea of putting the character element inside another, either pronoun itself or one called usage, which would supply a further contextual control. (Early experiments with usage suggest an attribute for classification, which I unhelpfully call type and which would have values such as pronoun, nickname and so on, and another for specifying case, eg subject, object, so as to distinguish between ‘he’ and ‘him’. A lot of work to go to for two- or three-letter words…)
*You can also use the position function to distinguish between the first (or indeed last) time an element is used and all the other times, which anyone who has typeset structured text will realise – thinking of elements in terms of ‘stylesheets’ – is potentially very useful indeed…)
|[xml categories]||Reference: strangerlove||2.08 pm|
It’s looking increasingly likely that I will want to refer to a specific test project within an entry, so I’ve come up with a new field – ‘Reference’, obviously. For the moment this will just be a name, but in time I hope to turn it into a link to a mini-site where anyone who’s interested can have a look at what I’m talking about…
|[General remarks]||10.55 am|
Some years ago, not long after I had first encountered xml, I expressed astonishment that no one was working on a quasi-WYSIWYG application for writing xml, à la html programs like Dreamweaver and GoLive. My interlocutor pointed out how difficult that would be for xml, as it would have to cater for any ‘dialect’ of the basic xml form that the user cared to create. I suppose I see his point – hence these ideas about a more or less (‘but rather less than more’) simple application of it dedicated to writing screenplays. But surely xsl is a different matter?
I dare say the answer is either ‘Yes and no’ or ‘It depends’ – it usually is. On the plus side (from where I’m sitting) is the fact that, unlike xml – of which it is a subset, after all – xsl has a limited set of elements and attributes. On the minus side is output: xsl is supposed to convert the source file to a wide range of different formats – xml itself, html, rtf, fo (ie, formatting objects – the ‘correct’ companion for xml/xsl), even TeX (my favoured format – as of course it would be…), etc, etc – each one of which is a huge, and slippery, can of worms.
There’s also the problem of input: the untrammelled xml source file raising its ugly head again. If this had dozens of levels and hundreds of elements, each with several attributes, it’s difficult to imagine any kind of GUI being capable of handling these in a user-friendly manner. (Of course, one argument might be that the dialect of xml used in this case was poorly planned and simply more complicated than it needed to be…)
But perhaps it would be possible to come up with a simple front end for xsl for not-very-complex source files and an xml output – as a start, at any rate. One might imagine a window on the left hand of the screen showing the elements and attributes from the source file (or its DTD/schema): the child elements indented from their parents, a line of attributes following after, a bit like the ‘list’ view of a folder’s contents in the Apple Finder. In the middle of the screen would be the xsl ‘work’ window and on the right would be a set of standard conversions – structural, calculated (sorting, if…then…, numbering) and individual (changing case, adding punctuation). Perhaps you could double-click on the element in question or drag it to the place you wanted.
I can’t quite get my head round this at the moment, or at any rate see it ‘in my mind’s eye’. (I suspect I need more coffee – or possibly less.) But hopefully it’s a start. Perhaps if I think in terms of the different ways I would want to convert a particular xml file, I might get a bit further.
The part of the application that stores information about the characters in the play should be impossible to miss when the user first opens ‘Player King’: possibly the first window the user sees is the ‘New character’ one. Or do we want the first thing they see to be a configuration window (so they can specify whether the play is in prose or verse (the ‘prose’ button needs to be the default, obviously), some forms of usage (standard British/US spelling/punctuation, or an external stylesheet – not to be confused with a typesetting/word-processing stylesheet for specifying fonts, etc – that the user can load), basic instructions about the appearance of the working window (colour of background, colour of text) which can be changed later on) so that the user can specify number of characters from the off? (There should obviously be a way of making new characters, and indeed this whole configuration window should be accessible from the menus.)
This configuration window, once OK’d, should be followed by an ‘Edit character’ window. In case the user simply wants to start writing dialogue, the character(s) should be assigned default names (eg ‘character1’, ‘character2’) – perhaps this would be a better option at the configuration window, where rather than pressing the ‘OK’ button, the user has the option to press a button that says something like ‘Start writing’, which automatically assigns default names to the number of characters already specified, and starts the play process. As the standard setup of the play window also opens a smaller window with the characters’ main details listed, from which the user can double-click or drag a character’s name into the main window to start a new speech. It should also be possible to use an auxiliary key (shift, say, or command) to click on a second character name (or more – perhaps there should also be a ‘Select all’ option), in case the speech is attributed to two (or more) people. (NB: Think about how to allow the user to convey the fact that two speeches are being said simultaneously.)
Other things this floating character window should have include a column with the specified keystroke for the character, and an option to edit a specific character. This takes us to the ‘Edit character’ window. This should have many different things one can specify about the character. Probably the most important, after name, are age, sex and race. All of these can remain unspecified without any problem, although it might be worth adding the value ‘Unspecified’ to the sex field, as the choice is so limited there (the user might well want to have the ‘Unspecified’ option in any case). ‘Age’ can be defined in so many different ways – a specific age (‘42’), a vague range (‘late 30s/early 40s’), a general pointer (‘middle-aged’, or its host of synonyms) – that it’s difficult to know how to proceed with this. The application could be primed to pick up on the first numbers/letters the user enters, to give him/her a number of options: if a number, then it assumes that he/she will be putting in a specific age, if ‘mid…’, then ‘middle-aged’, if ‘lat…’ or ‘ear…’, then a list of ages begin ‘late’ or ‘early’.
As for names, perhaps the first field should be for the name which will be used for the character name at the beginning of a speech. Next to these are a number of tick boxes, ‘Forename’, ‘Surname’, ‘Nickname’, which the user can click (if he/she doesn’t click one of these, then there should be a tick box ‘Unspecified’, when gets ticked). Fields lower down in the window – which I currently conceive as two columns – actually allow for the proper entry of forename/surname/nickname, and obviously as an appropriate box is ticked, the relevant field is automatically filled in.
Apart from being of dubious political correctness, the ‘Race’ field is likely to be even vaguer than the age one. But many authors want to put this information in. It might be best to have a pretty comprehensive value list, which the author can add to as necessary.
(Incidentally, the point behind getting ‘useful’ information like this is so that it can be used for casting purposes.)
NB Things to think about: if the setting is in different periods (how to show the age difference?); if the character needs to be played by different actors.
|[User interface]||11.52 am|
One of the key reasons for using xml for this application is to avoid a particular problem I often encounter when editing plays for publication, which is that a play comes to us from the author in Word, say, and having been copy-edited and formatted according to our house style using InDesign, is returned to the author as hard copy (print-outs) or a pdf, only for him/her to send back a revised version in Word again – thus rendering the work on the earlier version pointless. The theory is that in this new process, the author can send a new version of the play (in xml – though he/she doesn’t need to know that), and the transformation file(s) and inDesign template will remain the same, and can be used to produce an updated version of the play automatically.
Still, I wonder how practical this is. Even assuming that the application is sufficiently comprehensive to mop up problems of spelling, punctuation and other orthography – without being so interventionist that it puts the author off completely – there are likely to be areas where the editor still needs to do some work, possibly leading to parallel updating by author and editor. (It may be a good idea to allow some sort of conflation of the updated bits of both versions – but even so, there may be errors that need to be sorted out in the new bits…) There’s also some sort of editorial principle at stake: that at some point the editor must take charge, at which point the author’s role comes down to approving or not. The advantage of this way of doing things is – hopefully – that the time needed to edit the play is reduced from days to hours.
Another important issue to remember is that it’s impossible to imagine how many ways a user might find to cock the program up…
|[User interface]||1.13 am|
One general idea I’ve had about ‘dialects’ of xml is that rather than trying to come up with a comprehensive ‘one size fits all’ version of xml like DocBook or TEI, we should be looking for relatively simple basic structures (that ‘relatively’ covering a multitude of sins) and bringing in modular, regular sets of categories as necessary. One example in the case of a play script would be a name & address structure, which would be used for administrative purposes: information about the author and his/her agent, for instance. (In word-processed scripts these addresses are often given on the titlepage.)
In a way it’s curious to think that there is no standard series of elements for a person’s name and address:* you would have thought that its obvious commercial utility would have produced one by now. Then again, these things do take a lot of planning, especially if you take unusual occurrences into account (pseudonyms – not so unusual among authors – being one obvious example). I suspect you could make your life much easier by being cunning about choosing good ‘default’ values for elements and attributes, so that you get the value you want by not mentioning them.
* There may well be a good example hidden away somewhere. I have a slight chicken and egg feeling about this, though: such examples won’t catch on until xml itself is better known, and xml isn’t likely to become better known until people starting incorporating more obviously practical solutions like modular, regular categories…
A couple of developments have made it seem feasible to start making notes on ‘Player King’, this wildly over-ambitious xml application I’m thinking about. First, I am making useful (if still basic) progress with xml/xslt; second, I have begun to see a way of ending up with a proper typeset file, courtesy of InDesign’s ability to match xml tags to user-defined styles. As I have a fairly straightforward template for producing the ‘matter’ of the plays (ie, dialogue and stage directions), I think that’s where I should start.
The template I am using is based on the one we use at Oberon, my (occasional) employers. The main formatting elements here are as follows:
Of these elements, the only ones that cannot be catered for by the styling capabilities of InDesign are the colon and space between the character name and the dialogue. However, since an author may demand a different layout for the character names (a popular one is bold and centred above the speech text), it would be unwise to include this orthography in the source xml file, whatever form that will eventually take. Instead, it seems the best approach will be to add the colon and space (or whatever) at an interim stage: as I also want to do some quite interesting things with the characters – in essence, define entities for each character that includes various standard bits of information about them (where relevant, age, sex, plus relationships to other characters) – which will need to be ‘clarified’ before it can be used in InDesign. (I already sense alarm bells due to xml/xslt’s handling, or non-handling, of white space.)
Ideally, the user interface for constructing characters would take you into a database-like structure, with a series of pre-defined fields for name, etc. My most way-out concept so far is to use the entity associated with each character in association with a sort of code, that defines the particular form of the name at a given point: full name, forename, nickname, pronoun. This is in accordance with something I think of as ‘the information iceberg’. But I am definitely – definitively? – getting ahead of myself…
|[General remarks]||11.20 pm|