... | ... | @@ -6,11 +6,11 @@ HTML Typescript has nothing to do with Word documents or word processing documen |
|
|
|
|
|
Among other things, this means that insofar as information available only from Word documents, is frequently ambiguous and underspecified, an HTML Typescript version must ideally mirror -- *reflect*, not resolve -- that ambiguity and underspecification. It should tell us -- albeit in HTML+CSS, a language we can understand -- exactly what we could know from the Word (if we understood WordML) - and no more. It should not make logical leaps, inferences, or even do very much in the way of translation.
|
|
|
|
|
|
### Design principles
|
|
|
### Aims
|
|
|
|
|
|
Within living memory, typewriters were used to create an artifact (namely a typed MS or typescript) amenable to a type- and print-based publication process. In such a system, although a material object, the (manipulated, annotated) typescript also provides for a kind of *encoding* (indeed in more than one modality), through which it can communicate intentions, among authors and from authors to editors to typesetters. Thus a typescript becomes an (almost literal) "platform" for the (print) production process, with what we would recognize as 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 -- quite -- an electronic doodle pad, nor a publishing application (either print or any other kind), but something in between. What we see are recognizably documents, with the features of formatted documents. But look at the code and you'll see -- once you get past its verbosity and redundancy -- the data is not in 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* (when you 'hit print' or view in a commodity browser) -- and as it turns out, these consistencies are precisely the guideposts we want, to make futher inferences, in a process of amelioration and improvement.
|
|
|
We are looking for an analogous sort of "paper functionality" in a form of HTML. It is not -- quite -- an electronic doodle pad, nor a publishing application (either print or any other kind), but something in between. What we see are recognizably documents, with the features of formatted documents. But look at the code and you'll see -- once you get past its verbosity and redundancy -- the data is not in 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* (when you 'hit print' or view in a commodity browser) -- which are, as it turns out, these consistencies are precisely the guideposts we want, to make futher inferences, in a process of amelioration and improvement.
|
|
|
|
|
|
We'll do this using basic-brain-dead 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. It should all be familiar stuff -- a bunch of "bad habits" that have to be cleaned up after and improved -- using HTML-capable toolkits in a shared space.
|
|
|
|
... | ... | |