In a previous post I took a look at the translation of Celtx to other languages (in Swedish), but here are my findings on how Celtx v2.9.1 is working with the content rather than displayed language. I’m focusing on the screenplay perspective, which is most interesting to me.
I’m making the tedious effort to study output files instead of looking at the source code, but when you save a script in Celtx it ends up in a project file with the extension .celtx, e.g. MyMovie.celtx. It’s just a zipped file which contains all the data for a project in clear text, so it’s easy to examine. A project library can contain several types of media and data, at the moment Celtx defaults to seven kinds of templates:
- Film (Screenplay)
- Audio-Visual (Directors schedule?)
- Theatre (Stageplay)
- Audio Play (BBC standard for radioplays/podcasts)
- Storyboard (based on index cards and images)
- Comic Book (comic stageplay)
- Novel (basic book writing).
The most important things, like the text of the script, are stored html text files, while the intelligence and meta data is stored in rdf/xml files.
Unzip/extracting a virgin MyMovie.celtx file gives:
This file contains the ”master” resource definitions for the whole project.
This file contains the meta data, the order of scenes, character info etc.
This file contains a ”scratchpad” placeholder for ideas and information, which is related to the script but put in a separate structure as to not interfere with the original script.
This file contains the actual/original screenplay script content, tagged with html.
If we add images/photos to the project they will appear next to the files above, as seen further down on this post.
Let’s have a look inside each file!
The local.rdf file
This file declares a Project Master ID (my wording), which all it’s containing rdf/xml files connect to, as well as telling what view was last open when we open Celtx. A project can contain a Novel, a Screenplay etc. This it’s all kept together logically in the local.rdf file.
It may look like this:
First we have the rdf/xml declaration, the usuals. The interesting parts are:
The ID’s of the contained content types/templates, in this case a Screenplay and it’s Master Catalog:
A Master Catalog is a view on tagged elements of a script, e.g. characters, sound effects, animals etc. and some meta data notes for each element (where applicable).
I’m guessing the Celtx Installation ID (my wording) is ”#$3DD1u”
The Screenplay ID is ”1kEqvojZWTHA”
The Master Catalog ID is ”vbHM8my1Pyk0”
The 12 character long strings are generated by Celtx and appears to be unique for each project file, while the Celtx Installation ID seems to stay fixed.
Then we have the declaration of what elements are open in the project, in this case the Master Catalog script:
Where the Master Project ID, again in lack of appropriate wording, is ”fly1RztQ01di”.
This file contains the brains and structure of e.g. a Screenplay script; the characters, the order of scenes, the meta data about characters etc. It does not contain the actual script contents, as they are stored in a separate html file.
The file is always initiated with an xml statement:
This is followed by the master RDF declaration:
At the bottom of the file we find this closing section:
Again we see a reference to the ”Master Project ID”: ”fly1RztQ01di”
EXPLORE: What is the cx:components ”U0xHoW9oCmfD”?
Between the initial and closing sections we find stuff more randomly ordered, or in reverse order? I guess it doesn’t really matter. Since most personal computers these days have a fair amount or RAM and CPU horsepower, and a screenplay script is just a couple of hundred pages (around 90-120 in case of Hollywood standard specs), it shouldn’t really matter from a performance perspective.
OK, moving on.
Scenes are stated like this:
dc:title="INT. SCENE 2 - NIGHT"
Where the non-obvious are:
sceneid A key linked to the content in the script-xeb.html file.
sortord Tells us the scene number.
cx:members (We'll figure this out later.)
cx:markup (We'll figure this out later.)
Cast is marked up like this, here with a character called ”Daniel”:
The cast characters are detailed in the Master Catalog view. Opening this in Celtx and adding info, this section can look like this:
NS1:character-full-name="Daniel The Barbarian"
dc:description="This is Daniels description: He's a mean bastard."
NS1:character-goal="Daniel wants to understand Celtx and improve it. He'd like to see a screenplay of his turn into a full feature film some day, but enjoys hacking Celtx for the fun of it."
NS1:character-ach_goal="The character's way to achieve his goal is to study the source code, understand rdf/xml better and then attempt to write and publish some extended features."
NS1:character-fam_back="Daniel is the only son in an intercontinental family."
NS1:character-habits="Dives into stuff 110% for a period of time. Then dives into something else. Zooms in and out of stuff quickly."
NS1:character-education="While a BSc in Mechanical Engineering, he's mostly self made when it comes to IT."
NS1:character-person="A nice guy."
NS1:character-likes="Watching good flicks, hunting and learning how stuff works."
NS1:character-dislikes="He dislikes the limited number of hours per day."
NS1:character-traits="My character traits are treating me well."
NS1:character-dist_feat="I'm so normal and have no distinguished features!"
NS1:character-weight="about 90 kg's, in a showroom mirror.">
In the Master Catalog we can add images/photos of the character.
The cx:media resource is thus ”WDOkyiQ3kwhM”
Further down in the project.rdf we find:
The image file protagonist.gif is stored in the root of the zipped .celtx file, next to the rdf files.
How does Celtx know that the image is contained related to the character, e.g. how does Celtx know what scenes this character is in? (as shown in Master Catalog)?
Ah! It adds a separate tag for this in the project.rdf file:
See! WDOkyiQ3kwhM is the resource ID in the cx:Cast for the character ”Daniel”, and it contains a reference to an element gZc7yg59RFIg, which in turn states it’s an image with the file name protagonist.gif!
Now we are getting at it. The project.rdf file is a sort of database, containing connections between different resources; be it scenes, characters and their meta data. We can start to work out a structured schema of how things are put together based upon these connecting ID’s.
Once we have a complete view of the schema, it’s easy to build things that need the meta data and structure, for instance export a custom report to Excel/LibreOffice/OpenOffice/Google Docs Sheets. If we know the XML structure of Final Draft, we can build an ”Export/Import Final Draft screenplay”. While this may be useful, my intention is to build something basic first. And I don’t have Final Draft to explore it’s structure. I’ll give this some more thought and try to come up with a useful ”Hello World” case eventually.