Ladies[1] and gentlemen of /prog/, on this historical day, I hereby pronounce BBCode failures to be abolished, for from this day onward, EXPERT PROGRAMMER and /g/roksi alike will be able to adorn their posts with the most civilized of markup languages Sexpcode!.
tag-name = alpha+
tag = verbatim-tag
| (tag-name (whitespace* "{" text "}")+)
`verbatim-tag' is defined as follows: let `delimiter' be a string not containing the character " " such that the concatenation of " ", `delimiter' and "}" is not a substring of `contents'. Then a valid `verbatim-tag' evaluating to `contents' is
\frac, \root, and \braces
While \array can be clumsily used to implement these, it is better to have dedicated tags for them in order to signal intent. A command-line viewer could render \frac{a}{b} as (a)/(b), for example.
\size
It is needed for things like large summation symbols.
\indices
\sup and \sub cannot be used simultaneously.
\abovebelow
This is needed for cases when subscripts and superscripts should be placed above and below a symbol, e.g. TeX code "\displaystyle{\sum_{i=1}^n}".
SPECIFICATIONS
For the scope of this specification, the special verbatim tag `v' shall not be considered a tag, and will instead be viewed as its contents, as text. The reason behind this is because the verbatim tag is merely a convenient way of escaping large blocks of text, and does not have any semantic meaning.
Passing the specified number of arguments is MANDATORY unless specified otherwise.
\q {quoted-text}
`quoted-text' SHOULD be rendered slightly indented.
\url {link} {content}
`content' SHOULD be rendered as a hyperlink towards `link'. `link' MUST NOT contain any tags.
\code {language} {source}
`source' SHOULD be rendered with the appropriate syntax colouring for `language'. `language' and `source' MUST NOT contain any tags.
\attachment {name} {mime-type} {gzipped-base64-data}
`gzipped-base64-data' SHOULD be made available through user action, and be automatically decompressed; it MUST be gzip-compressed (RFC 1952) using the DEFLATE method. `gzipped-base64-data' MUST NOT contain any non-base64 characters or tags, except for whitespace which MUST be ignored. `mime-type' MUST be the MIME type of the uncompressed data. `name' MUST be a suggested filename for the data; as such, it must NOT contain the backslash or forward slash characters. The attachment SHOULD be rendered as a hyperlink including the `name' and `mime-type' information. An estimate of the uncompressed data size MAY also be included.
\c {colour} {content}
`colour' MUST be three hexadecimal digits corresponding to red, green and blue, representing the colour with which `content' should be rendered. If multiple \c tags are nested, then the innermost takes precedence.
\frac {numerator} {denominator}
`numerator' and `denominator' SHOULD be rendered as a fraction, i.e. `numerator' should be rendered atop of `denominator' with a horizontal bar between them.
\root {radix} {content}
`radix' and `content' SHOULD be rendered as a root. See figure 1.
----------------
`radix'/ \
/ `content'
\/
Figure 1: the \root tag
\size {font-size} {content}
`font-size' MUST be a positive integer. `content' SHOULD be rendered using a font size of `(* (/ font-size 10) current-size)' where `current-size' is the current size. A renderer MAY limit the maximum size obtainable in this manner.
\indices {content} {r-sup} {r-sub} ({l-sup} {l-sub})?
`content' SHOULD be rendered with `r-sup', `r-sub', `l-sup', and `r-sub' as indices (see figure 2). If the `l-sup' and `l-sub' tags are ommitted, their values are taken to be the empty string.
PART 2/3
\abovebelow {content} {above-content} {below-content}
`above-content' SHOULD be rendered above `content' and `below-content' below `content' (see figure 3).
\braces {brace-info} ({content} {brace-info})*
`brace-info' MUST be the concatenation of `brace-type' and `brace-height'. `brace-type' MUST be one of the following characters: "()[]{}<>|d" (where "{" and "}" were properly escaped). While the others are self-explanatory, the "d" case in `brace-type' SHOULD be rendered as a double vertical bar (e.g. as in the usual notation for vector norm), and "<" and ">" SHOULD be rendered as angle brackets. `brace-height' MUST be one of the following:
If `brace-height' is an empty string, then the height of the rendered brace SHOULD be `content-bbox-height', that is, the height of the bounding box encompassing all `content's.
If `brace-height' is a positive integer, then the height of the rendered brace SHOULD be `(* (/ brace-height 10) current-line-height)'.
If `brace-height' is the character "+" followed by a positive integer `x', then the height of the rendered brace SHOULD be `(+ content-bbox-height (* (/ x 10) current-line-height))'.
\spoilernote {content} {explanation}
`content' SHOULD be rendered in a particular way to mark this tag (e.g. using a different background colour). The `explanation' SHOULD NOT be visible until the user takes explicit action to interact with the `content' (e.g. click on it). The explanation MUST then be easy to hide by user action (e.g. by clicking again).
Name:
3/32013-08-23 7:12
PART 3/3
\array {array-info} {cell}+
It is simpler in this case to give the formal grammar:
sectionspec = "|" | "d" | ":" | " "
repetition = positive-integer
borderspec = repetition (sectionspec repetition?)* | (sectionspec repetition?)+
noinherit = "*"
alignment = (h-align v-align? | v-align h-align?)
h-align = "l" | "c" | "r"
v-align = "t" | "m" | "b"
array-info = borderspec "," borderspec
cell-info = alignment ("," borderspec? ("," borderspec?)?)? noinherit?
cell = cell-info ";" cell-content
`borderspec' defines both how long (in columns or rows) a border is and how each column-long or row-long section SHOULD be rendered: "|" means solid line, "d" means two parallel solid lines, ":" means dashed line, and " " means no line. If `repetition' is present, then the `sectionspec' preceding it SHALL be interpreted as having been repeated `repetition' times; if `repetition' is present but there is no preceding `sectionspec', then this SHALL be interpreted as " " repeated `repetition' times.
For both `array-info' and `cell-info', the first `borderspec' refers to horizontal borders, and the second `borderspec' refers to vertical borders. We shall refer to these as `h-borderspec' and `v-borderspec'.
For a cell, the `h-borderspec' and `v-borderspec' define its bottom and right borders respectively (and in particular, their lengths).
The position at which the next cell shall be placed (or, more precisely, the leftmost topmost position it will span) MUST be the lowest (y,x) coordinate (in lexicographic order) that is not spanned by any cell, where `x' is column number and `y' is row number. The cells MUST form a partition over the set of valid array coordinates.
For the array, the `h-borderspec' and `v-borderspec' in `array-info' define its top and left borders respectively.
For a cell, if `borderspec' (vertical or horizontal) is empty or absent, then its `borderspec' SHALL be the first `sectionspec' of the corresponding `borderspec' of the last specified cell that was not marked `noinherit'. If no such cell exists, then `borderspec' SHALL be the first `sectionspec' of the corresponding `borderspec' of `array-info'.
The `alignment' specifies how `cell-content' is aligned within the cell. "l" means left, "c" means centre, "r" means right, "t" means top, "m" means middle, and "b" means bottom.
If `h-align' or `v-align' is unspecified for a cell, then the cell MUST inherit the corresponding alignment from the last specified cell that was not marked `noinherit'. If there is no such cell, then "c" (if `h-align') or "m" (if `v-align') SHALL be used instead.
`cell-content' SHOULD NOT word wrap, and the array's rows and columns should enlarge to fit all `cell-content's.
\table {table-info} {column-widths} {cell}+
Everything is exactly the same as \array (with `table-info' playing the role of `array-info'), with the difference that `cell-content' now word wraps, and that the extra argument `column-widths' MUST contain a comma-separated list of `column-width'. This list MUST NOT have more elements than the table has columns, but may have less. `column-width' must either be the empty string or a positive integer followed by "%". If `column-width' is an empty string or is not stated, the renderer is free to decide the corresponding column's width. If `column-width' is a positive integer followed by "%", then the corresponding column SHOULD have width `(* (/ column-width 100) table-width)'.