... | ... | @@ -8,9 +8,11 @@ In particular, this means that insofar as as information available only from Wor |
|
|
|
|
|
### Design principles
|
|
|
|
|
|
A typewriter can be used to create an artifact (namely a typed MS or typescript) amenable to a type- and print-based publication process. Although a material object, the typescript also typically provides for a kind of *encoding* by which it can communicate intentions from author to editors. Of course a typescript is also a "platform" for changes, with a kind of "production loop" built around it (wherein it might be said to evolve in form, from fair copy to galleys to printed production).
|
|
|
A typewriter can be used to create an artifact (namely a typed MS or typescript) amenable to a type- and print-based publication process. Although a material object, the typescript also typically provides for a kind of *encoding* (indeed in more than one modality) by which it can communicate intentions from author to editors. Of course a typescript is also a "platform" for changes, with a kind of "production loop" built around it -- wherein it might be said to evolve in form, from submitted fair copy to galleys to printed production.
|
|
|
|
|
|
We aim to provide the same sort of "paper functionality" in HTML. It is not an electronic scratchpad - what we see are recognizably documents, with the features of formatted documents. But it isn't a formal or even very regular arrangement. It reflects whatever regularies "emerge" from the habits and practices of its original authors - those and no more. Which is good since those regularities (such as they are) are exactly the ones we wish to see.
|
|
|
We aim to provide the same sort of "paper functionality" in HTML. It is not -- quite -- an electronic doodle pad - what we see are recognizably documents, with the features of formatted documents. But it isn't a formally controlled or even very regular arrangement. Paradoxically, since no structure is imposed or formal control exerted, what stands out is consistencies in the *way things are made to appear* (in typescript, on a printed page; with HTML, in a commodity browser) -- and it proves that those consistencies are precisely the guideposts we want, to make futher inferences.
|
|
|
|
|
|
We'll do this using brain-dead Level 2 HTML/CSS: basically a few structural divs for framing, then `p` elements with an assortment of inline mixed content including `b`, `i`, `u`. There will be resort to CSS to describe things that are not easily described using tags alone (such as margins and indents on paragraphs). But nothing should be obscure to the web developer.
|
|
|
|
|
|
### Translation principles
|
|
|
|
... | ... | @@ -30,6 +32,10 @@ The expectation of HTML Typescript is that we wish the thing to be a basis for i |
|
|
|
|
|
## XSweet implementation
|
|
|
|
|
|
XSweet produces a variety of HTML typescript in its "snapshot" of a Word .docx (Open Office XML) document.
|
|
|
|
|
|
Also, other XSweet components are designed to provide various services in processing HTML Typescript, enabling it to be tweaked, tuned, and improved in ways custom-fit to particular documents and content types. For example the HTMLTweak module provides for simple logic-based renaming of `class` and `style` assignments supporting global cleanup/enhancement of HTML Typescript documents.
|
|
|
|
|
|
### Syntactic requirements (these preserve interoperability with the XML transformation/query stack)
|
|
|
|
|
|
* XML syntax w/ no tag minimization. Everything in XHTML namespace; otherwise avoid namespace complications
|
... | ... | |