SGML for captioning

SGML can be applied to the practice of captioning film and video. SGML encodes structure, not overt form. But overt form is what most captioning viewers – and commentators – are familiar with.

Let's take an example and think of the uses of italics in American captioning. Here italics are the overt format, and the list below itemizes some of the underlying structure or function represented by italics.

• All the usual uses from print typography: Titles of artworks (books, movies, plays, videos), names of ships, some foreign or cited words, among others; also, crucially, for emphasis
• Narration
• Internal monologues or thinking
• Flashbacks
• Flash-forwards
• Video-within-video (in the work of NCI)
• Quotations within quotations (NCI)
• Offscreen voices, as in the spooky words Ray Kinsella hears in Field of Dreams
• Absolutely any speech from any character not visible when that character begins to speak (Captions, Inc. and, in many cases, the TKCaption Center)
• Annotations of sound effects:
  • In background only in the convention of Captions, Inc.
  • Lowercase within parentheses in the convention the Caption Center, necessitating blank spaces within the parens (since the italic toggle inserts a blank space)
  • Only if part of a video within a video or another higher-level use of italics in the convention of NCI
• Backup vocals (particularly the Caption Center, but the Caption Center is inconsistent in this use)
• Italics within italics, which require turning italics off temporarily

There are others, and this is not an invitation to spend the rest of our lives itemizing them. However, the point here is that SGML for access will need to encode the function and then let the interpreting program decide on format. For example:

<sound effect>phone rings</sound effect>

could take the overt form of

( phone rings )

at the Caption Center (apologies for the use of the <I> tag) or

[PHONE RINGS]

at NCI or

[ Phone Rings ]

at Captions, Inc.

If we encoded the caption file structurally, we could very easily transfer information among captioners. (Yes, overseas, too.) That includes the most common transformation – syndication reformats or anything that simply requires a global offset in timecode, or an offset after every commercial break.

<offset 0:01:13.26>
<offset 0>

Or have the machine do a first pass at calculating new timecodes for an NTSC-to-PAL transfer:

<fps original=30 new=25>

where fps = frames per second. This could save NCI lots of time in reformatting Line 21 CC movies for UK Line 22 CC, not that NCI is overburdened with Line 22 business or all that interested in open standardization.

Also, information could be formatted for different kinds of displays, viz.:

• Original TeleCaption decoder (now completely outdated – listed here for the sake of argument)
• TeleCaption II decoder and compatibles
• FCC-compatible decoders at various levels (strict minimal compliance, with uppercase only; full character set with all four Line 21 fields, etc.)
• An LED display of the sort the NCAM RearWindow system uses (with no italics possible)
• ASCII
• Any of dozens of word-processor or DTP formats
• PDF
• PostScript
• Contracted Braille (for which SGML DTDs are abundant already)
• Offscreen large-print display for visually-impaired viewers (with limited positioning capability due to size constraints and with no italics)
• World System Teletext
• IBM CGA (used by many overhead projectors)

simply by selecting that output device as the desired one – all from the same easily-encoded data.

Get the idea?