HAHA! commit
This commit is contained in:
parent
2ac63f44b6
commit
dfa2f8569c
119
Lesson1.md
Normal file
119
Lesson1.md
Normal file
@ -0,0 +1,119 @@
|
||||
---
|
||||
bibliography: wwwrite.bib
|
||||
cover: img/enco.png
|
||||
---
|
||||
|
||||
## Text Encoding
|
||||
|
||||
We believe in approaching text writing by first understanding the core inscription mechanism upheld by modern computing machine. In this lesson we will hence look at how text and characters are inscribed and represented internally within computers. More specifically we will look at standards of text encoding (and decoding) and see how text editors can decode such encoding.
|
||||
|
||||
### Goals
|
||||
|
||||
The aim of this lesson is to present the various ways that computers represent text internally, that is, characters as digits. The lesson is tailored in giving the reader the basic knowledge of standards that establish the quanta of text (data). Our hope in doing so is to give a feel of a kind of materiality of text and present the ways in which various levels of abstraction are applied to it.
|
||||
|
||||
In a nutshell, the goals of this lesson are:
|
||||
|
||||
1. Understand the various ways in which characters are represented and encoded as digits.
|
||||
2. Derive a basic understanding of how proprietary text formats are encoded.
|
||||
3. Develop a critical stance on why proprietary text formats might be problematic.
|
||||
4. Develop a critical stance on why standardized open text formats are important and ubiquitous.
|
||||
5. Learn how to use a plain text editor to write, view and inspect different open standards encodings of a given text file.
|
||||
|
||||
### History
|
||||
|
||||
As everyone heard of the byte format? If you didn't it's about time you do as you employ this legacy format daily when using your computer. A byte is the most basic quanta of computing and is composed of 8 bits, where a bit stands for what is commonly represented by a 0 or 1. Hence a byte is a 8-bits "packet" which can represent decimal numbers ranging from 0 to 255 (or -128 to 127). In this lesson we will use the [Hexadecimal](https://en.wikipedia.org/wiki/Hexadecimal) notation to represent bytes. A byte is an historical format and encapsulate the most basic data structure in computing machinery, a standard introduced by IBM for its flagship [IBM/360](http://www.computermuseum.li/Testpage/IBM-360-1964.htm) mainframe machine in 1964.[^1]
|
||||
|
||||
Roughly at the same time (1963) another (updated) standard was devised for the encoding of characters: ASCII [ref]. ASCII conceived a 7-bit format for characters that was factorised into an 8-bit format on the IBM/360. With a 7-bit format, ASCII had the possibility to encode 127 characters. However, the IBM/360 opted to use the legacy [EBCDIC](https://en.wikipedia.org/wiki/EBCDIC) 8-bit format as default character set (dubbed "charset") on all software developed for the IBM/360[^2]. Hence the mass adoption of ASCII as main default charset in computing systems came years after mainly with the advent of PCs.
|
||||
|
||||
Is ASCII still in use today? Yes and no. ASCII has some important limitations as it was designed for Latin-based languages and does not support non-Latin characters (hence a 7-bit format for an Latin alphabet). With the wide spread of PCs around the world and the rise of the Internet as main communication infrastructure, the need for a single character format (albeit a Universal Format) accounting for both Latin and non-Latin characters (Cyrillic, Hebrew, Arabic, Turkish to name a few) was imminent at the beginning for the 90s.
|
||||
|
||||
Hence the establishment of the Unicode standard which aim is to devise and maintain a Universal Character Set (UCS) composed of special codes points for each character (a kind of "meta"-charset if you want, composed of specific unicode codes)[^3]. Unicode does not specify specific encodings for its code points. Rather, encodings are part of specific implementations of the UCS such as UTF (UCS Transformation Format). The most notable UTF being UTF-8.[^4] The special feature of UTF-8 is that it is directly backward compatible with ASCII (an 8-bit ASCII character as the same encoding as its UTF-8 version) and has the property of being variable in length, meaning that Latin characters are encoded with a single byte while other non-Latin characters may be encoded with up to 4 bytes.[^5] Nowadays, UTF-8 is one of the most (if not _the_ most) mass adopted / ubiquitous character encoding format.[^6]
|
||||
|
||||
|
||||
### How
|
||||
|
||||
Let's start with a very simple example to illustrate how text is encoded.
|
||||
|
||||
The following sentence
|
||||
|
||||
this is a sentence encoded in UTF-8.
|
||||
|
||||
is equivalent to UTF-8
|
||||
|
||||
7468 6973 2069 7320 6120 7365 6e74 656e 6365 2065 6e63 6f64 6564 2069 6e20 5554 462d 382e
|
||||
|
||||
and Unicode
|
||||
|
||||
U+0074 U+0068 U+0069 U+0073 U+0020 U+0069 U+0073 U+0020 U+0061 U+0020 U+0073 U+0065 U+006e U+0074 U+0065 U+006e U+0063 U+0065 U+0020 U+0065 U+006e U+0063 U+006f U+0064 U+0065 U+0064 U+0020 U+0069 U+006e U+0020 U+0055 U+0054 U+0046 U+002d U+0038 U+002e
|
||||
|
||||
Now the same sentence in Vietnamese
|
||||
|
||||
đây là một câu UTF-8.
|
||||
|
||||
is equivalent to UTF-8
|
||||
|
||||
c491 c3a2 7920 6cc3 a020 6de1 bb99 7420 63c3 a275 2055 5446 2d38 2e
|
||||
|
||||
and Unicode
|
||||
|
||||
U+0111 U+00e2 U+0079 U+0020 U+006c U+00e0 U+0020 U+006d U+1ed9 U+0074 U+0020 U+0063 U+00e2 U+0075 U+0020 U+0055 U+0054 U+0046 U+002d U+0038 U+002e
|
||||
|
||||
A few observations from the examples above are worth noting:
|
||||
|
||||
1. For the English sentence, the UTF-8 encoding and Unicode representation are basically the same. This is because what we are looking at is basically straight ASCII! Unicode's UCS was designed to integrate ASCII into it's core coding scheme and hence used the same codes for its Latin-based subset. UTF-8 implements this (obviously) into its encoding scheme.
|
||||
|
||||
2. UTF-8 encoding of the English sentence is far more compact then the Unicode UCS. For a single character, UTF-8 utilises two bytes rather than four from the UCS.
|
||||
|
||||
3. For the Vietnamese sentence, things get a little more interesting. Here the UTF-8 encoding and Unicode representation are _not_ the same. As explained in the last section, UTF-8 encoding format and Unicode code points are not meant to be equivalent, one is a standard (Unicode) while the other is the implementation of this standard (UTF-8).
|
||||
|
||||
4. UTF-8 encoding of the Vietnamese sentence is _not_ necessarily more compact then Unicode's UCS. In fact we see UTF-8 utilising four bytes to encode some characters (remember that UTF-8 is of variable-length). For example the character 'â' is 'U+00e2' in UCS (two significant bytes) while 'c3a2' in UTF-8 (four significant bytes). A great chart to look at the various codes and encoding can be found here: [http://utf8-chartable.de](http://utf8-chartable.de)
|
||||
|
||||
At this point, we should stress the fact that what is inscribed in computing memory is the _encoding_ of text and not its Unicode representation. In other words, UTF-8 is the scheme from which computers inscribe text to physical memory using their read/write mechanisms. What is inscribed physically are single bits following the UTF-8 encodings scheme that gives meaning to 8-bit "packets" as characters. In the example above we have employed the hexadecimal notation to represent such "packets"/data. This is, of course, an kind of abstraction from the physical layer where text is actually inscribed, a convenient way for us humans to decipher and group bits. It nonetheless gives us a feel for the type of "materiality" of text inscribed on and manipulated by computing machine. For a more in depth analysis of physical inscription mechanisms, we refer the forensics work of Kirschenbaum [@kirschenbaum_mechanisms:_2012] on the subject.
|
||||
|
||||
#### (Plain) Text Editors
|
||||
|
||||
But how do I go about and start looking up the encoding of a particular text? Well it is pretty simple: don't use word processing software; use a [plain text editor](https://en.wikipedia.org/wiki/Text_editor). For the examples above we've used [Sublime Text](http://www.sublimetext.com)[^7] to manipulate and reveal encodings of our sentences. The idea with plain text editors is that they give it all, they are usually very basic in appearance yet usually have striking features that are central to the practice of computer programming. There exist a panoply of good and powerful text editors[^8] and some are even legacy editors such as [Emacs](https://www.gnu.org/software/emacs/) and [Vi(m)](http://www.vim.org). In this lesson (and the remaining ones) we will use Sublime to illustrate techniques and concept, yet any other editors would suffice without a doubt.
|
||||
|
||||
Now equipped with an editor, let's look up what a word processing file looks like:
|
||||
|
||||

|
||||
|
||||
To select the encoding of a file using Sublime: __Menu__ -> __File__ -> __Reopen with Encoding__
|
||||
|
||||
The above file is an Apple Pages file that we have opened using Sublime with UTF-8 decoding.
|
||||
|
||||
As you can see there is many characters that do not read properly, that is, not human readable. In fact, we can see that UTF-8 decodes the bytes in the file and maps their content to some Unicode "control" character. These "control" characters are part of the UCS and are characters representing computer commands if you like, rather than elements of an alphabet. For example a "new line" character representing a new line in a text (when the "return" key is pressed on a keyboard) has a "LF" (Line Feed) symbol with UCS U+000A value. There exists a vaietry of such characters.[^9]
|
||||
|
||||
However, in the case of the Apple Pages file, these "control" characters are meaningless as they do not obviously follow the Unicode standard. Instead Pages inserts into it's text specific commands that only have meaning for the Apple Pages program. In short, these are bytes that have meaning only to Apple and their specific regime of encoding files. Such commands may refer to specific ways to display certain types of characters, or perhaps signify the beginning of a paragraph, or specify a font to render text, or even be the data of an image (who knows?). Pages is not a standard format but a proprietary one, therefore it is not possible to instruct my text editor on how to decode the bytes found in the Pages document. In a sense, in having all data part of a single file (information about the design, layout, font, etc.) it makes the files overly complex compared to plain text format. As a result, word processing files tend to be larger in size than plain UTF-8 encoded ones. The text from the file above has 1 389 characters. Its Apples Pages file is composed of 179 759 bytes while its plain UTF-8 version only 1 391 bytes (two extra bytes for the "EOF" control character).
|
||||
|
||||
In turn the obvious unreadability of proprietary word processing file formats (such as Apple Pages, MS Word) coupled with their tendency to bloat file, makes them problematic in terms of politics of encoding, usability and efficiency. Hence, standards like UTF-8 and the use of plain text editors are viable alternative for writing academic text and sustained by a practice that is unbounded by obfuscating interests and techniques. What is human-readable is human-understandable.
|
||||
|
||||
### Extra
|
||||
|
||||
As an exercise for this lesson, please feel free to experiment with [Sublime Text](http://www.sublimetext.com) (especially its encoding features): __Menu__ -> __File__ -> __Reopen with Encoding__
|
||||
|
||||
[Sublime Text 2 Official Documentation](http://www.sublimetext.com/docs/2/)
|
||||
|
||||
[Sublime Text 2 Non-Official Documentation](http://sublime-text-unofficial-documentation.readthedocs.org/en/sublime-text-2/)
|
||||
|
||||
Note: If you are a plain text editing novice, please make sure you understand just-enough basics to start. Some of the tutorials only are tailored for advanced programmers and their jargon may be confusing at times.
|
||||
|
||||
### References
|
||||
|
||||
[^1]: The IBM/360 is one of the most sold computer of its time. For a discussion about the 8-bit byte format see _Data Format_ section in [@amdahl_architecture_1964].
|
||||
|
||||
[^2]: See section _ASCII vs BCD codes_ in [@amdahl_architecture_1964] and for more information about the history of the ASCII format see the writings of [Bob Bemer](http://www.bobbemer.com/BYTE.HTM).
|
||||
|
||||
[^3]: Unicode codes are represented with a 'U' prefix before their numerical codes. For a table of all the codes, refer to [http://unicode-table.com/](http://unicode-table.com/)
|
||||
|
||||
[^4]: See also UTF-16, UTF-32 and the Unicode [FAQ](http://www.unicode.org/faq/utf_bom.html) for disambiguation.
|
||||
|
||||
[^5]: UTF-8 was conceived by [Ken Thompson](https://en.wikipedia.org/wiki/Ken_Thompson) and [Rob Pike](https://en.wikipedia.org/wiki/Rob_Pike) on a placemat in a [New Jersey diner in 1992](http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt).
|
||||
|
||||
[^6]: Especially on the Internet -- see character encodings historical trend [chart](http://w3techs.com/technologies/history_overview/character_encoding/ms/y).
|
||||
|
||||
[^7]: Although moving to [Atom](https://atom.io) eminently.
|
||||
|
||||
[^8]: For a list of such editors please refer to [this article](https://en.wikipedia.org/wiki/Comparison_of_text_editors).
|
||||
|
||||
[^9]: For a comprehensible explanation of these codes, please refer to historical [RFC20](https://tools.ietf.org/html/rfc20). The concept of control codes was introduced by legacy [Baudot (1870) and Murray codes (1901)](https://en.wikipedia.org/wiki/Baudot_code) who were standard coding techniques up until the advent of aforementioned EBCDIC and ASCII.
|
||||
61
Lesson2.md
Normal file
61
Lesson2.md
Normal file
@ -0,0 +1,61 @@
|
||||
|
||||
## CLI or the Command Line Interface
|
||||
|
||||
The Command Line Interface is the most common and pervasive interface directly linking fingers typing on a keyboard (text) and the computer (commands). The CLI is a legacy mode of operating computing system which can be traced back to early telegraphic devices. In this lesson we will look at your computer's own CLI and present ways in which you can use it to write, manipulate, analyse and transform text on your own computer system.
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
### Goals
|
||||
|
||||
The aim of this lesson is for readers to develop an appreciation of the advantages of using the CLI for certain types of work involving text editing on a computer. As the CLI itself is text based, our goal is to present the history of the CLI and discuss how text-based computer interfaces are still up to this day on of the most important ways to communicate with the computer systems.
|
||||
|
||||
The goals of the lesson are:
|
||||
|
||||
1. Understand the historical precedents leading to the development of modern CLI.
|
||||
2. Acquire basic knowledge on how to operate the CLI of your own computer.
|
||||
3. Develop the ability to recognize where and when the CLI is a better alternative than other types of computer interfaces (mainly graphical).
|
||||
4. Develop a critical perspective on why the CLI matters in some situation and when it does not.
|
||||
5. Acquire just-enough basic CLI vocabulary to be used in future (research) work.
|
||||
|
||||
|
||||
### How
|
||||
|
||||
Command Line Interface ---> Command Line Interpreter (shell)
|
||||
|
||||
Prompt
|
||||
|
||||
Commands
|
||||
|
||||
<!--
|
||||
<ls>
|
||||
|
||||
<mv>
|
||||
|
||||
<cp>
|
||||
|
||||
<file>
|
||||
|
||||
<fmt> <fold>
|
||||
|
||||
<iconv>
|
||||
|
||||
<wc> + <nl>
|
||||
|
||||
<grep>
|
||||
|
||||
Results
|
||||
|
||||
### Extra
|
||||
|
||||
<banner>
|
||||
-->
|
||||
|
||||
[^1]: Something that is easily forgotten in the era of ubiquitous computer screens. For a discussion on the topic see Nick Montfort's essay [Continuous Paper: The Early Materiality and Workings of Electronic Literature](http://nickm.com/writing/essays/continuous_paper_mla.html).
|
||||
|
||||
[^2]: [Datapoint 3300 brochure](http://archive.computerhistory.org/resources/text/Computer_Terminal_Corporation/ComputerTerminalCorporation.Datapoint3300.1969.102646159.pdf).
|
||||
|
||||
[^3]: In fact Victor Poor from CTC devised the architecture and instruction set. The instruction set is, to this day, found (a revised version of course) on Intel's flagship x86 architecture, the most pervasive microprocessor architecture of all time (typing this text was processed by a x86 microprocessor).
|
||||
|
||||
[^4]: And subsequently the legacy 8-bit Intel 8080, 16-bit Intel 8086 and the whole x86 family of microprocessors. For all the details of the development of the Intel 8008, please refer to [this document](http://archive.computerhistory.org/resources/access/text/2012/07/102657982-05-01-acc.pdf).
|
||||
11
Lesson3.md
Normal file
11
Lesson3.md
Normal file
@ -0,0 +1,11 @@
|
||||
## Markup / Markdown
|
||||
|
||||
### Goals
|
||||
|
||||
### History
|
||||
|
||||
### How
|
||||
|
||||
### Extra
|
||||
|
||||
https://packagecontrol.io/packages/Pandoc%20Academic
|
||||
9
Lesson4.md
Normal file
9
Lesson4.md
Normal file
@ -0,0 +1,9 @@
|
||||
## (Text) Processor
|
||||
|
||||
### Goals
|
||||
|
||||
### History
|
||||
|
||||
### How
|
||||
|
||||
### Extra
|
||||
9
Lesson5.md
Normal file
9
Lesson5.md
Normal file
@ -0,0 +1,9 @@
|
||||
## Bibliographer
|
||||
|
||||
### Goals
|
||||
|
||||
### History
|
||||
|
||||
### How
|
||||
|
||||
### Extra
|
||||
9
Lesson6.md
Normal file
9
Lesson6.md
Normal file
@ -0,0 +1,9 @@
|
||||
## Styling
|
||||
|
||||
### Goals
|
||||
|
||||
### History
|
||||
|
||||
### How
|
||||
|
||||
### Extra
|
||||
63
index.md
Normal file
63
index.md
Normal file
@ -0,0 +1,63 @@
|
||||
---
|
||||
title: WWWRITING WITH WIT
|
||||
bibliography: wwwrite.bib
|
||||
cover: img/DSP6.png
|
||||
---
|
||||
|
||||
## Intent
|
||||
|
||||
|
||||
This site is intended to introduce humanities research writers how to write text in a modern fashion using their computers. The aim of the lessons listed below are points of departure for the practice of writing text using simple, basic yet advance systems and technologies. Part of this endeavour is first and foremost to empower writers to use these systems in presenting simple didactic material working towards bootstrapping their understanding of writing technologies and help them develop a new type of literacy (albeit an electronic one). Another goals of this site is to present the historical trajectories of modern writing systems by emphasising on their phylogenesis. Computerised writing systems and related methods (as we will see) have a long history following that of writing itself; the double-valance between the practice of writing and the mode of inscription (technologies) is an important (research) topic in the humanities [@pontin_how_2012; @kirschenbaum_bookwriting_2013; @kirschenbaum_mechanisms:_2012; @kittler_discourse_1990].
|
||||
|
||||
## Philosophy
|
||||
|
||||
The idea in compiling this site-lesson is two fold:
|
||||
|
||||
(1) Present an alternative to the use of proprietary software for writing academic texts:
|
||||
|
||||
Considering the hegemonic use of proprietary software to write academic and non-academic texts (MS Word, Google Docs, Apple Pages, etc.) it is important to underline alternatives as these software not only “hide” their inner workings to scrutiny but most importantly may fall short in providing writers with adequate functionality required in writing academic texts [^1]. Obfuscation is impractical (and problematic) obviously so for academics in the Humanities.
|
||||
|
||||
|
||||
We believe in texts that we can read, that is, we will utilise (as much as possible) software which is made “open” for us to read the source code and formats that are [human-readable](https://en.wikipedia.org/wiki/Human-readable_medium) as opposed to solely [machine-readable](https://en.wikipedia.org/wiki/Machine-readable_data). Hence, throughout the lessons, we will be inspecting files and writing ones that are augmented with special codes that machines can understand. This idea of writing "meta-data" into the text or more precisely _markup_ text in a file is very important in making sure the text is human _and_ machine readable.
|
||||
|
||||
(2) Offer a glimpse into methods, practices and systems of software writing:
|
||||
|
||||
As you may already know, writing software is primarily a textual-based practice. Writing code is all about text, keyboards, text editors, line count, syntax and the likes. Hence an important amount of systems and technologies have been devised for the composition of software (as text). From syntax highlighting to version control, these systems have a long history and can possibly provide academic writers with powerful literary tools that can enable them to bolster their prose.[^2] In exposing (and historicising) these systems our objective is for the reader to relate to modern software writing systems not as merely a tool but as system with a culture. In no way we expect readers to become "programmers", far from this, we would rather present them the basics of writing text using (modern) computer systems while hoping that they'll develop a critical stance on these systems' genesis, conditions, limitations and capabilites.
|
||||
|
||||
## Scheme
|
||||
|
||||
The current site is segmented in six lessons covering the (very) basics of writing academic texts on a computer.[^3] The overall composition of these lessons is by no mean derived from obscure "Principles" or (even worst) "Best-practices" but rather stand as loosely coupled set of lessons that can be traversed all together (or not) in a short period of time. The site is neither a manual nor a manifesto and should be seen as a starting point into further developing (creative) technics and methods in text writing.
|
||||
|
||||
* [Lesson 1: Text Encoding](/)
|
||||
|
||||
Covers fundamentals of representation of text looking up how text is encoded/decoded as data.
|
||||
|
||||
* [Lesson 2: CLI or the Command Line Interface](/)
|
||||
|
||||
Presents how one can manipulate files and issue computing commands using what is known as a terminal.
|
||||
|
||||
* [Lesson 3: Markup / Markdown](/)
|
||||
|
||||
Introduces a markup language ([Markdown](http://daringfireball.net/projects/markdown/)) that is used to format and annotate text.
|
||||
|
||||
* [Lesson 4: (Text/Document) Processor](/)
|
||||
|
||||
Introduces a text / document processor ([Pandoc](http://johnmacfarlane.net/pandoc/)) which converts files written in a format into another.
|
||||
|
||||
* [Lesson 5: Bibliographer](/)
|
||||
|
||||
Looks at how to compile and maintain a bibliography using open source software ([Zotero](https://www.zotero.org)) and export references into a document
|
||||
|
||||
* [Lesson 6: Styling](/)
|
||||
|
||||
Discuss how to style (colour, margins, cover image, etc.) a given output from the text / document processor
|
||||
|
||||
As a final note worth mentioning (before delving further): all the lessons of this site, including this page, have been (are) written using the aforementioned encodings and systems. Hence, for the curious, the reader can lookup the files, modify and compile them to bootstrap their writing project. Whatever you see on this site is made available for you to read, modify, etc.
|
||||
|
||||
## References
|
||||
|
||||
[^1]: Literally fall short of basic features– i.e. can’t format a bibliography for example– or disable these features by design as [Antifeatures](https://www.fsf.org/bulletin/2007/fall/antifeatures/).
|
||||
|
||||
[^2]: As a side note, for those who are interested in reading about code as poetry (and more) — please refer to recent work by @cox_speaking_2013 and @montfort_10_2014.
|
||||
|
||||
[^3]: That is, writing text on a computers in 2015.
|
||||
483
style/style.css
Normal file
483
style/style.css
Normal file
@ -0,0 +1,483 @@
|
||||
/*
|
||||
Style.css
|
||||
A revised Pandoc/Markdown/Multi-Markdown CSS stylesheet tailored for html5
|
||||
output for the wwwriting site hosted on ....
|
||||
Author: gauthiier
|
||||
Revised: 10 Feb 2015
|
||||
|
||||
This file is based on:
|
||||
|
||||
Buttondown
|
||||
A Markdown/MultiMarkdown/Pandoc HTML output CSS stylesheet
|
||||
Author: Ryan Gray
|
||||
Date: 15 Feb 2011
|
||||
Revised: 21 Feb 2012
|
||||
|
||||
General style is clean, with minimal re-definition of the defaults or
|
||||
overrides of user font settings. The body text and header styles are
|
||||
left alone except title, author and date classes are centered. A Pandoc TOC
|
||||
is not printed, URLs are printed after hyperlinks in parentheses.
|
||||
Block quotes are italicized. Tables are lightly styled with lines above
|
||||
and below the table and below the header with a boldface header. Code
|
||||
blocks are line wrapped.
|
||||
|
||||
All elements that Pandoc and MultiMarkdown use should be listed here, even
|
||||
if the style is empty so you can easily add styling to anything.
|
||||
|
||||
There are some elements in here for HTML5 output of Pandoc, but I have not
|
||||
gotten around to testing that yet.
|
||||
*/
|
||||
|
||||
/* NOTES:
|
||||
|
||||
Stuff tried and failed:
|
||||
|
||||
It seems that specifying font-family:serif in Safari will always use
|
||||
Times New Roman rather than the user's preferences setting.
|
||||
|
||||
Making the font size different or a fixed value for print in case the screen
|
||||
font size is making the print font too big: Making font-size different for
|
||||
print than for screen causes horizontal lines to disappear in math when using
|
||||
MathJax under Safari.
|
||||
*/
|
||||
|
||||
/* ---- Front Matter ---- */
|
||||
|
||||
/* Pandoc header DIV. Contains .title, .author and .date. Comes before div#TOC.
|
||||
Only appears if one of those three are in the document.
|
||||
*/
|
||||
|
||||
div#header, header
|
||||
{
|
||||
/* Put border on bottom. Separates it from TOC or body that comes after it. */
|
||||
border-bottom: 1px solid #aaa;
|
||||
margin-bottom: 0.5em;
|
||||
}
|
||||
|
||||
.title /* Pandoc title header (h1.title) */
|
||||
{
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.author, .date /* Pandoc author(s) and date headers (h2.author and h3.date) */
|
||||
{
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
/* Pandoc table of contents DIV when using the --toc option.
|
||||
NOTE: this doesn't support Pandoc's --id-prefix option for #TOC and #header.
|
||||
Probably would need to use div[id$='TOC'] and div[id$='header'] as selectors.
|
||||
*/
|
||||
|
||||
div#TOC, nav#TOC
|
||||
{
|
||||
/* Put border on bottom to separate it from body. */
|
||||
border-bottom: 1px solid #aaa;
|
||||
margin-bottom: 0.5em;
|
||||
}
|
||||
|
||||
@media print
|
||||
{
|
||||
div#TOC, nav#TOC
|
||||
{
|
||||
/* Don't display TOC in print */
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
/* ---- Headers and sections ---- */
|
||||
|
||||
h1, h2, h3, h4, h5, h6
|
||||
{
|
||||
/* font-family: "Helvetica Neue", Helvetica, "Liberation Sans", Calibri, Arial, sans-serif; /* Sans-serif headers */
|
||||
|
||||
font-family: "Liberation Serif", "Georgia", "Times New Roman", serif; /* Serif headers */
|
||||
|
||||
page-break-after: avoid; /* Firefox, Chrome, and Safari do not support the property value "avoid" */
|
||||
}
|
||||
|
||||
/* Pandoc with --section-divs option */
|
||||
|
||||
div div, section section /* Nested sections */
|
||||
{
|
||||
margin-left: 2em; /* This will increasingly indent nested header sections */
|
||||
}
|
||||
|
||||
p {}
|
||||
|
||||
/* Main container for the whole content / body section -- html5 */
|
||||
content {
|
||||
padding: 0.9em;
|
||||
max-width: 45em;
|
||||
display: block;
|
||||
text-align: justify;
|
||||
margin: auto;
|
||||
word-wrap: break-word;
|
||||
}
|
||||
|
||||
.references {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
blockquote
|
||||
{
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
li /* All list items */
|
||||
{
|
||||
}
|
||||
|
||||
li > p /* Loosely spaced list item */
|
||||
{
|
||||
margin-top: 1em; /* IE: lack of space above a <li> when the item is inside a <p> */
|
||||
}
|
||||
|
||||
ul /* Whole unordered list */
|
||||
{
|
||||
}
|
||||
|
||||
ul li /* Unordered list item */
|
||||
{
|
||||
}
|
||||
|
||||
ol /* Whole ordered list */
|
||||
{
|
||||
}
|
||||
|
||||
ol li /* Ordered list item */
|
||||
{
|
||||
}
|
||||
|
||||
hr {}
|
||||
|
||||
/* ---- Some span elements --- */
|
||||
|
||||
sub /* Subscripts. Pandoc: H~2~O */
|
||||
{
|
||||
}
|
||||
|
||||
sup /* Superscripts. Pandoc: The 2^nd^ try. */
|
||||
{
|
||||
}
|
||||
|
||||
em /* Emphasis. Markdown: *emphasis* or _emphasis_ */
|
||||
{
|
||||
}
|
||||
|
||||
em > em /* Emphasis within emphasis: *This is all *emphasized* except that* */
|
||||
{
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
strong /* Markdown **strong** or __strong__ */
|
||||
{
|
||||
}
|
||||
|
||||
/* ---- Links (anchors) ---- */
|
||||
|
||||
a /* All links */
|
||||
{
|
||||
/* Keep links clean. On screen, they are colored; in print, they do nothing anyway. */
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
@media screen
|
||||
{
|
||||
a:hover
|
||||
{
|
||||
/* On hover, we indicate a bit more that it is a link. */
|
||||
text-decoration: underline;
|
||||
}
|
||||
}
|
||||
|
||||
@media print
|
||||
{
|
||||
a {
|
||||
/* In print, a colored link is useless, so un-style it. */
|
||||
color: black;
|
||||
background: transparent;
|
||||
}
|
||||
|
||||
a[href^="http://"]:after, a[href^="https://"]:after
|
||||
{
|
||||
/* However, links that go somewhere else, might be useful to the reader,
|
||||
so for http and https links, print the URL after what was the link
|
||||
text in parens
|
||||
*/
|
||||
content: " (" attr(href) ") ";
|
||||
font-size: 90%;
|
||||
}
|
||||
}
|
||||
|
||||
/* ---- Images ---- */
|
||||
|
||||
img
|
||||
{
|
||||
/* Let it be inline left/right where it wants to be, but verticality make
|
||||
it in the middle to look nicer, but opinions differ, and if in a multi-line
|
||||
paragraph, it might not be so great.
|
||||
*/
|
||||
vertical-align: middle;
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
div.figure /* Pandoc figure-style image */
|
||||
{
|
||||
/* Center the image and caption */
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
text-align: center;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
/** EXXXTRA **/
|
||||
figure /* Pandoc figure-style image */
|
||||
{
|
||||
/* Center the image and caption */
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
text-align: center;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
p.caption /* Pandoc figure-style caption within div.figure */
|
||||
{
|
||||
/* Inherits div.figure props by default */
|
||||
}
|
||||
|
||||
/* ---- Code blocks and spans ---- */
|
||||
|
||||
pre, code
|
||||
{
|
||||
background-color: #fdf7ee;
|
||||
/* BEGIN word wrap */
|
||||
/* Need all the following to word wrap instead of scroll box */
|
||||
/* This will override the overflow:auto if present */
|
||||
white-space: pre-wrap; /* css-3 */
|
||||
white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
|
||||
white-space: -pre-wrap; /* Opera 4-6 */
|
||||
white-space: -o-pre-wrap; /* Opera 7 */
|
||||
word-wrap: break-word; /* Internet Explorer 5.5+ */
|
||||
/* END word wrap */
|
||||
}
|
||||
|
||||
pre /* Code blocks */
|
||||
{
|
||||
/* Distinguish pre blocks from other text by more than the font with a background tint. */
|
||||
padding: 0.5em; /* Since we have a background color */
|
||||
border-radius: 5px; /* Softens it */
|
||||
/* Give it a some definition */
|
||||
border: 1px solid #aaa;
|
||||
/* Set it off left and right, seems to look a bit nicer when we have a background */
|
||||
margin-left: 0.5em;
|
||||
margin-right: 0.5em;
|
||||
}
|
||||
|
||||
@media screen
|
||||
{
|
||||
pre
|
||||
{
|
||||
/* On screen, use an auto scroll box for long lines, unless word-wrap is enabled */
|
||||
white-space: pre;
|
||||
overflow: auto;
|
||||
/* Dotted looks better on screen and solid seems to print better. */
|
||||
border: 1px dotted #777;
|
||||
}
|
||||
}
|
||||
|
||||
code /* All inline code spans */
|
||||
{
|
||||
}
|
||||
|
||||
p > code, li > code /* Code spans in paragraphs and tight lists */
|
||||
{
|
||||
/* Pad a little from adjacent text */
|
||||
padding-left: 2px;
|
||||
padding-right: 2px;
|
||||
}
|
||||
|
||||
li > p code /* Code span in a loose list */
|
||||
{
|
||||
/* We have room for some more background color above and below */
|
||||
padding: 2px;
|
||||
}
|
||||
|
||||
/* ---- Math ---- */
|
||||
|
||||
span.math /* Pandoc inline math default and --jsmath inline math */
|
||||
{
|
||||
/* Tried font-style:italic here, and it messed up MathJax rendering in some browsers. Maybe don't mess with at all. */
|
||||
}
|
||||
|
||||
div.math /* Pandoc --jsmath display math */
|
||||
{
|
||||
}
|
||||
|
||||
span.LaTeX /* Pandoc --latexmathml math */
|
||||
{
|
||||
}
|
||||
|
||||
eq /* Pandoc --gladtex math */
|
||||
{
|
||||
}
|
||||
|
||||
/* ---- Tables ---- */
|
||||
|
||||
/* A clean textbook-like style with horizontal lines above and below and under
|
||||
the header. Rows highlight on hover to help scanning the table on screen.
|
||||
*/
|
||||
|
||||
table
|
||||
{
|
||||
border-collapse: collapse;
|
||||
border-spacing: 0; /* IE 6 */
|
||||
|
||||
border-bottom: 2pt solid #000;
|
||||
border-top: 2pt solid #000; /* The caption on top will not have a bottom-border */
|
||||
|
||||
/* Center */
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
}
|
||||
|
||||
thead /* Entire table header */
|
||||
{
|
||||
border-bottom: 1pt solid #000;
|
||||
background-color: #eee; /* Does this BG print well? */
|
||||
}
|
||||
|
||||
tr.header /* Each header row */
|
||||
{
|
||||
}
|
||||
|
||||
tbody /* Entire table body */
|
||||
{
|
||||
}
|
||||
|
||||
/* Table body rows */
|
||||
|
||||
tr {
|
||||
}
|
||||
tr.odd:hover, tr.even:hover /* Use .odd and .even classes to avoid styling rows in other tables */
|
||||
{
|
||||
background-color: #eee;
|
||||
}
|
||||
|
||||
/* Odd and even rows */
|
||||
tr.odd {}
|
||||
tr.even {}
|
||||
|
||||
td, th /* Table cells and table header cells */
|
||||
{
|
||||
vertical-align: top; /* Word */
|
||||
vertical-align: baseline; /* Others */
|
||||
padding-left: 0.5em;
|
||||
padding-right: 0.5em;
|
||||
padding-top: 0.2em;
|
||||
padding-bottom: 0.2em;
|
||||
}
|
||||
|
||||
/* Removes padding on left and right of table for a tight look. Good if thead has no background color*/
|
||||
/*
|
||||
tr td:last-child, tr th:last-child
|
||||
{
|
||||
padding-right: 0;
|
||||
}
|
||||
tr td:first-child, tr th:first-child
|
||||
{
|
||||
padding-left: 0;
|
||||
}
|
||||
*/
|
||||
|
||||
th /* Table header cells */
|
||||
{
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
tfoot /* Table footer (what appears here if caption is on top?) */
|
||||
{
|
||||
}
|
||||
|
||||
caption /* This is for a table caption tag, not the p.caption Pandoc uses in a div.figure */
|
||||
{
|
||||
caption-side: top;
|
||||
border: none;
|
||||
font-size: 0.9em;
|
||||
font-style: italic;
|
||||
text-align: center;
|
||||
margin-bottom: 0.3em; /* Good for when on top */
|
||||
padding-bottom: 0.2em;
|
||||
}
|
||||
|
||||
/* ---- Definition lists ---- */
|
||||
|
||||
dl /* The whole list */
|
||||
{
|
||||
border-top: 2pt solid black;
|
||||
padding-top: 0.5em;
|
||||
border-bottom: 2pt solid black;
|
||||
}
|
||||
|
||||
dt /* Definition term */
|
||||
{
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
dd+dt /* 2nd or greater term in the list */
|
||||
{
|
||||
border-top: 1pt solid black;
|
||||
padding-top: 0.5em;
|
||||
}
|
||||
|
||||
dd /* A definition */
|
||||
{
|
||||
margin-bottom: 0.5em;
|
||||
}
|
||||
|
||||
dd+dd /* 2nd or greater definition of a term */
|
||||
{
|
||||
border-top: 1px solid black; /* To separate multiple definitions */
|
||||
}
|
||||
|
||||
/* ---- Footnotes ---- */
|
||||
|
||||
a.footnote, a.footnoteRef { /* Pandoc, MultiMarkdown footnote links */
|
||||
font-size: small;
|
||||
vertical-align: text-top;
|
||||
}
|
||||
|
||||
a[href^="#fnref"], a.reversefootnote /* Pandoc, MultiMarkdown, ?? footnote back links */
|
||||
{
|
||||
}
|
||||
|
||||
@media print
|
||||
{
|
||||
a[href^="#fnref"], a.reversefootnote /* Pandoc, MultiMarkdown */
|
||||
{
|
||||
/* Don't display these at all in print since the arrow is only something to click on */
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
div.footnotes /* Pandoc footnotes div at end of the document */
|
||||
{
|
||||
}
|
||||
|
||||
div.footnotes li[id^="fn"] /* A footnote item within that div */
|
||||
{
|
||||
}
|
||||
|
||||
/* You can class stuff as "noprint" to not print.
|
||||
Useful since you can't set this media conditional inside an HTML element's
|
||||
style attribute (I think), and you don't want to make another stylesheet that
|
||||
imports this one and adds a class just to do this.
|
||||
*/
|
||||
|
||||
@media print
|
||||
{
|
||||
.noprint
|
||||
{
|
||||
display:none;
|
||||
}
|
||||
}
|
||||
71
style/template.html5
Normal file
71
style/template.html5
Normal file
@ -0,0 +1,71 @@
|
||||
<!DOCTYPE html>
|
||||
<html$if(lang)$ lang="$lang$"$endif$>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="generator" content="pandoc">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||||
$for(author-meta)$
|
||||
<meta name="author" content="$author-meta$">
|
||||
$endfor$
|
||||
$if(date-meta)$
|
||||
<meta name="dcterms.date" content="$date-meta$">
|
||||
$endif$
|
||||
<title>$if(title-prefix)$$title-prefix$ - $endif$$pagetitle$</title>
|
||||
<style type="text/css">code{white-space: pre;}</style>
|
||||
<!--[if lt IE 9]>
|
||||
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
|
||||
<![endif]-->
|
||||
$if(quotes)$
|
||||
<style type="text/css">q { quotes: "“" "”" "‘" "’"; }</style>
|
||||
$endif$
|
||||
$if(highlighting-css)$
|
||||
<style type="text/css">
|
||||
$highlighting-css$
|
||||
</style>
|
||||
$endif$
|
||||
$for(css)$
|
||||
<link rel="stylesheet" href="$css$">
|
||||
$endfor$
|
||||
$if(math)$
|
||||
$math$
|
||||
$endif$
|
||||
$for(header-includes)$
|
||||
$header-includes$
|
||||
$endfor$
|
||||
</head>
|
||||
<body>
|
||||
$for(include-before)$
|
||||
$include-before$
|
||||
$endfor$
|
||||
<content>
|
||||
$if(title)$
|
||||
<header>
|
||||
<h1 class="title">$title$</h1>
|
||||
$if(subtitle)$
|
||||
<h1 class="subtitle">$subtitle$</h1>
|
||||
$endif$
|
||||
$if(cover)$
|
||||
<figure>
|
||||
<img src="$cover$"/>
|
||||
</figure>
|
||||
$endif$
|
||||
$for(author)$
|
||||
<h2 class="author">$author$</h2>
|
||||
$endfor$
|
||||
$if(date)$
|
||||
<h3 class="date">$date$</h3>
|
||||
$endif$
|
||||
</header>
|
||||
$endif$
|
||||
$if(toc)$
|
||||
<nav id="$idprefix$TOC">
|
||||
$toc$
|
||||
</nav>
|
||||
$endif$
|
||||
$body$
|
||||
</content>
|
||||
$for(include-after)$
|
||||
$include-after$
|
||||
$endfor$
|
||||
</body>
|
||||
</html>
|
||||
89
wwwrite.bib
Normal file
89
wwwrite.bib
Normal file
@ -0,0 +1,89 @@
|
||||
|
||||
@misc{pontin_how_2012,
|
||||
title = {How Authors Write},
|
||||
url = {http://www.technologyreview.com/review/429654/how-authors-write/},
|
||||
abstract = {The technologies of composition, not new media, inspire innovations in literary styles and forms.},
|
||||
urldate = {2015-02-07},
|
||||
journal = {{MIT} Technology Review},
|
||||
author = {Pontin, Jason},
|
||||
month = oct,
|
||||
year = {2012},
|
||||
keywords = {wwwriting},
|
||||
file = {Snapshot:/Users/gauthiier/docs/~~~/texts/_systems/zozo/storage/Z6GX74EM/Pontin - 2012 - How Authors Write.html:text/html}
|
||||
}
|
||||
|
||||
@book{montfort_10_2014,
|
||||
title = {10 {PRINT} {CHR}\$(205.5+{RND}(1))[semi-colon] [colon] {GOTO} 10},
|
||||
isbn = {9780262526746 0262526743},
|
||||
language = {English},
|
||||
author = {Montfort, Nick},
|
||||
year = {2014},
|
||||
keywords = {wwwriting}
|
||||
}
|
||||
|
||||
@book{kittler_discourse_1990,
|
||||
title = {Discourse Networks 1800/1900},
|
||||
isbn = {9780804720991},
|
||||
abstract = {This is a highly original book about the connections between historical moment, social structure, technology, communication systems, and what is said and thought using these systems--notably literature. The author focuses on the differences between 'discourse networks' in 1800 and in 1900, in the process developing a new analysis of the shift from romanticism to modernism. The work might be classified as a German equivalent to the New Historicism that is currently of great interest among American literary scholars, both in the intellectual influences to which Kittler responds and in his concern to ground literature in the most concrete details of historical reality. The artful structure of the book begins with Goethe's Faust and ends with Valéry's Faust. In the 1800 section, the author discusses how language was learned, the emergence of the modern university, the associated beginning of the interpretation of contemporary literature, and the canonization of literature. Among the writers and works Kittler analyzes in addition to Goethe's Faust are Schlegel, Hegel, E.T.A. Hoffman's 'The Golden Pot', and Goethe's Tasso. The 1900 section argues that the new discourse network in which literature is situated in the modern period is characterized by new technological media--film, the photograph, and the typewritten page--and the crisis that these caused for literary production. Along the way, the author discusses the work of Nietzsche, Gertrude Stein, Mallarmé, Bram Stroker, the Surrealists, Rilke, Kafka, and Freud, among others.},
|
||||
language = {en},
|
||||
publisher = {Stanford University Press},
|
||||
author = {Kittler, Friedrich A.},
|
||||
year = {1990},
|
||||
keywords = {Literary Criticism / Books \& Reading, Literary Criticism / European / German, wwwriting}
|
||||
}
|
||||
|
||||
@book{kirschenbaum_mechanisms_2012,
|
||||
address = {Cambridge, Mass.; London},
|
||||
title = {Mechanisms: new media and the forensic imagination},
|
||||
isbn = {9780262517409 026251740X},
|
||||
shorttitle = {Mechanisms},
|
||||
language = {English},
|
||||
publisher = {{MIT} Press},
|
||||
author = {Kirschenbaum, Matthew G.},
|
||||
year = {2012},
|
||||
keywords = {wwwriting}
|
||||
}
|
||||
|
||||
@article{kirschenbaum_book-writing_2013,
|
||||
title = {The Book-Writing Machine},
|
||||
issn = {1091-2339},
|
||||
url = {http://www.slate.com/articles/arts/books/2013/03/len_deighton_s_bomber_the_first_book_ever_written_on_a_word_processor.html},
|
||||
abstract = {What was the first novel ever written on a word processor?},
|
||||
language = {en-{US}},
|
||||
urldate = {2015-02-07},
|
||||
journal = {Slate},
|
||||
author = {Kirschenbaum, Matthew},
|
||||
month = mar,
|
||||
year = {2013},
|
||||
keywords = {wwwriting},
|
||||
file = {Slate Snapshot:/Users/gauthiier/docs/~~~/texts/_systems/zozo/storage/IW6SPMUD/len_deighton_s_bomber_the_first_book_ever_written_on_a_word_processor.single.html:text/html}
|
||||
}
|
||||
|
||||
@book{cox_speaking_2013,
|
||||
address = {Cambridge, Mass},
|
||||
series = {Software studies},
|
||||
title = {Speaking code: coding as aesthetic and political expression},
|
||||
isbn = {9780262018364},
|
||||
shorttitle = {Speaking code},
|
||||
publisher = {The {MIT} Press},
|
||||
author = {Cox, Geoff},
|
||||
collaborator = {McLean, Alex},
|
||||
year = {2013},
|
||||
keywords = {Computer prose, Philosophy, Programming languages (Electronic computers), Source code (Computer science), Syntax, wwwriting}
|
||||
}
|
||||
|
||||
@article{amdahl_architecture_1964,
|
||||
title = {Architecture of the {IBM} System/360},
|
||||
volume = {8},
|
||||
issn = {0018-8646},
|
||||
doi = {10.1147/rd.82.0087},
|
||||
abstract = {The architecture of the newly announced {IBM} System/360 features four innovations: 1. An approach to storage which permits and exploits very large capacities, hierarchies of speeds, read-only storage for microprogram control, flexible storage protection, and simple program relocation. 2. An input/output system offering new degrees of concurrent operation, compatible channel operation, data rates approaching 5,000,000 characters/second, integrated design of hardware and software, a new low-cost, multiple-channel package sharing main-frame hardware, new provisions for device status information, and a standard channel interface between central processing unit and input/output devices. 3. A truly general-purpose machine organization offering new supervisor facilities, powerful logical processing operations, and a wide variety of data formats. 4. Strict upward and downward machine-language compatibility over a line of six models having a performance range factor of 50. This paper discusses in detail the objectives of the design and the rationale for the main features of the architecture. Emphasis is given to the problems raised by the need for compatibility among central processing units of various size and by the conflicting demands of commercial, scientific, real-time, and logical information processing. A tabular summary of the architecture is shown in the Appendices.},
|
||||
number = {2},
|
||||
journal = {{IBM} Journal of Research and Development},
|
||||
author = {Amdahl, G.M. and Blaauw, G.A. and Brooks, F.P.},
|
||||
month = apr,
|
||||
year = {1964},
|
||||
keywords = {wwwriting},
|
||||
pages = {87--101},
|
||||
file = {IEEE Xplore Abstract Record:/Users/gauthiier/docs/~~~/texts/_systems/zozo/storage/SWZK9CWM/articleDetails.html:text/html}
|
||||
}
|
||||
Loading…
x
Reference in New Issue
Block a user