Differences From
Artifact [c71fe3a9e8]:
4 4 dict: http://ʞ.cc/fic/spirals/glossary
5 5
6 6 the cortav [!format] can be called [!cortavgil], or [!gil cortavi], to differentiate it from the reference implementation [!cortavsir] or [!sir cortavi].
7 7
8 8 %toc
9 9
10 10 ## cortav vs. markdown
11 -the most important difference between cortav and markdown is that cortav is strictly line-oriented. this choice was made to ensure that cortav was relatively easy to parse. so while a simple [$.ct] file may look a bit like a [$.md] file, in reality it's a lot closer to gemtext than any flavor of markdown.
11 +the most important difference between cortav and markdown is that cortav is strictly line-oriented. this choice was made to ensure that cortav was relatively easy to parse. so while a simple [`.ct] file may look a bit like a [`.md] file, in reality it's a lot closer to gemtext than any flavor of markdown.
12 12
13 13 ## encoding
14 14 a cortav document is made up of a sequence of codepoints. UTF-8 must be supported, but other encodings (such as UTF-32 or C6B) may be supported as well. lines will be derived by splitting the codepoints at the linefeed character or equivalent. note that unearthly encodings like C6B or EBCDIC will need to select their own control sequences.
15 15
16 16 ## file type
17 17 a cortav source file is identified using a file extension, file type, and/or magic byte sequence.
18 18
19 19 three file extensions are defined as identifying a cortav source file. where relevant, all must be recognized as indicating a cortav source file.
20 -* [$ct] is the shorthand extension
21 -* [$cortav] is the canonical disambiguation extension, for use in circumstances where [$*.ct] is already defined to mean a different file format.
22 -* [$] is the canonical Corran extension, a byte sequence comprising the unicode codepoints [$U+E3CE U+E3BD]. where the filesystem in question does not specify a filename encoding, the bytes should be expressed in UTF-8.
20 +* [`ct] is the shorthand extension
21 +* [`cortav] is the canonical disambiguation extension, for use in circumstances where [`*.ct] is already defined to mean a different file format.
22 +* [`] is the canonical Corran extension, a byte sequence comprising the unicode codepoints [`U+E3CE U+E3BD]. where the filesystem in question does not specify a filename encoding, the bytes should be expressed in UTF-8.
23 23
24 24 three more extensions are reserved for identifying a cortav intent file.
25 -* [$ctc] is the shorthand extension
26 -* [$cortavcun] is the canonical disambiguation extension
27 -* [$] is the canonical Corran extension, a byte sequence comprising the unicode codepoints [$U+E3CE U+E3BD U+E3CE]. where the filesystem in question does not specify a filename encoding, the bytes should be expressed in UTF-8.
25 +* [`ctc] is the shorthand extension
26 +* [`cortavcun] is the canonical disambiguation extension
27 +* [`] is the canonical Corran extension, a byte sequence comprising the unicode codepoints [`U+E3CE U+E3BD U+E3CE]. where the filesystem in question does not specify a filename encoding, the bytes should be expressed in UTF-8.
28 28
29 29 on systems which use metadata to encode filetype, two values are defined to identify cortav source files
30 -* [$text/x-cortav] should be used when strings or arbitrary byte sequences are supported
31 -* [$CTAV] (that is, the byte sequence [$0x43 0x54 0x41 0x56]) should be used on systems that support only 32-bit file types/4-character type codes like Classic Mac OS.
30 +* [`text/x-cortav] should be used when strings or arbitrary byte sequences are supported
31 +* [`CTAV] (that is, the byte sequence [`0x43 54 41 56]) should be used on systems that support only 32-bit file types/4-character type codes like Classic Mac OS.
32 32
33 33 two more values are defined to identify cortav intent files.
34 -* [$text/x-cortav-intent]
35 -* [$CTVC] (the byte sequence [$0x43 0x54 0x56 0x43])
34 +* [`text/x-cortav-intent]
35 +* [`CTVC] (the byte sequence [`0x43 54 56 43])
36 36
37 -on systems which do not define a canonical way of encoding the filetype but support extended attributes of some kind, such as linux, an attribute named [$mime] may be created and given the value [$text/x-cortav] or [$text/x-cortav-intent]; alternatively, extensions may be used.
37 +on systems which do not define a canonical way of encoding the filetype but support extended attributes of some kind, such as linux, an attribute named [$mime] may be created and given the value [`text/x-cortav] or [`text/x-cortav-intent]; alternatively, extensions may be used.
38 38
39 39 it is also possible to indicate the nature of a cortav file without using filesystem metadata. this is done by prefixing the file with a magic byte sequence. the sequence used depends on the encoding.
40 -* for UTF-8 and ASCII, [$%ct[!\\n]] (that is, the byte sequence [$0x25 0x63 0x74 0x0A]) should be used
41 -* for C6B, the file should begin with the word [$] (that is, the byte sequence [$0x03 0x07 0x3E 0x2D]).
40 +* for UTF-8 and ASCII plain text files, [`%ct[!\\n]] (that is, the byte sequence [`0x25 63 74 0A]) should be used
41 +* for C6B+PS files (parastream), the file should begin with the paragraph [`], which equates to the byte sequence [` 0x3E 2E 14 0C 01 04 00 00 00 03 07 3E 2D], including the parastream header).
42 42 consequently, this sequence should be ignored by a cortav parser at the start of a file (except as an indication of file format).
43 43
44 -for FreeDesktop-based systems, the [$velartrill-cortav.xml] file included in the repository supplies mappings for the extensions and magic byte sequences. a script is also included which can be registered with xdg-open so that double-clicking on a cortav file will render it out and open it in your default web browser.
44 +for FreeDesktop-based systems, the [`build/velartrill-cortav.xml] file included in the repository supplies mappings for the extensions and magic byte sequences. a script is also included which can be registered with xdg-open so that double-clicking on a cortav file will render it out and open it in your default web browser. [`$ make install] will generate the necessary FreeDesktop XML files and register them, as well as install the script and the [`cortav] executable itself. for more information see [>refimpl-build building the reference implementation].
45 45
46 46 ## structure
47 47 cortav is based on an HTML-like block model, where a document consists of sections, which are made up of blocks, which may contain a sequence of spans. flows of text are automatically conjoined into spans, and blocks are separated by one or more newlines. this means that, unlike in markdown, a single logical paragraph [*cannot] span multiple ASCII lines. the primary purpose of this was to ensure ease of parsing, but also, both markdown and cortav are supposed to be readable from within a plain text editor. this is the 21st century. every reasonable text editor supports soft word wrap, and if yours doesn't, that's entirely your own damn fault.
48 48
49 -the first character(s) of every line (the "control sequence") indicates the role of that line. if no control sequence is recognized, the sequence [$.] is implied instead. the standard line classes and their associated control sequences are listed below. some control sequences have alternate forms, in order to support modern, readable unicode characters as well as plain ascii text.
50 -
51 -* paragraphs (. ¶ ❡): a paragraph is a simple block of text. the period control sequence is only necessary if the paragraph text begins with something that would otherwise be interpreted as a control sequence.
52 -* newlines (\\): inserts a line break into previous paragraph and attaches the following text. mostly useful for poetry or lyrics.
53 -* section starts (# §): starts a new section. all sections have an associated depth, determined by the number of sequence repetitions (e.g. "###" indicates depth-three"). sections may have headers and IDs; both are optional. IDs, if present, are a sequence of raw-text immediately following the hash marks. if the line has one or more space character followed by styled-text, a header will be attached. the character immediately following the hashes can specify a particular type of section. e.g.:
54 -** [$#] is a simple section break.
55 -** [$#anchor] opens a new section with the ID [$anchor].
56 -** [$# header] opens a new section with the title "header".
57 -** [$#anchor header] opens a new section with both the ID [$anchor] and the title "header".
58 -** [$#>conversation] opens a blockquote section named [$conversation] without a header.
59 -** [$#^id] opens a footnote section for the multiline footnote [$id]. the ID must be specified.
60 -** [$#$id] opens the multiline macro [$id]. the ID must be specified.
61 -** [$#&id mime] opens a new inline object [$id] of type [$mime]. useful for embedding SVGs. the ID and mime type must be specified.
62 -* lists (* :): these are like paragraph nodes, but list nodes that occur next to each other will be arranged so as to show they compose a sequence. depth is determined by the number of stars/colons. like headers, a list entry may have an ID that can be used to refer back to it; it is indicated in the same way. if colons are used, this indicates that the order of the items is signifiant. :-lists and *-lists may be intermixed; however, note than only the last character in the sequence actually controls the depth type.
63 -* directives (%): a directive issues a hint to the renderer in the form of an arbitrary string. directives are normally ignored if they are not supported, but you may cause a warning to be emitted where the directive is not supported with [$%!] or mark a directive critical with [$%!!] so that rendering will entirely fail if it cannot be parsed.
64 -* comments (%%): a comment is a line of text that is simply ignored by the renderer.
65 -* asides (!): indicates text that diverges from the narrative, and can be skipped without interrupting it. think of it like block-level parentheses. asides which follow one another are merged as paragraphs of the same aside, usually represented as a sort of box. if the first line of an aside contains a colon, the stretch of styled-text from the beginning to the aside to the colon will be treated as a "type heading," e.g. "Warning:"
66 -* code (~~~): a line beginning with ~~~ begins or terminates a block of code. the opening line should look like one of the below
67 -** [$~~~]
68 -** [$~~~ language] (markdown-style shorthand syntax)
69 -** [$~~~ \[language\] ~~~] (cortav syntax)
70 -** [$~~~ \[language\] #id ~~~]
71 -** [$~~~ title ~~~]
72 -** [$~~~ title \[language\] ~~~]
73 -** [$~~~ \[language\] title ~~~]
74 -** [$~~~ title \[language\] #id ~~~]
75 -* reference (tab): a line beginning with a tab is treated as a "reference." references hold out-of-line metadata for preceding text like links and footnotes. a reference consists of an identifier followed by a colon and an arbitrary number of spaces or tabs, followed by text. whether this text is interpreted as raw-text or styled-text depends on the context in which the reference is used.
76 -* quotation (<): a line of the form [$<[!name]> [!quote]] denotes an utterance by [$name].
77 -* blockquote (>): alternate blockquote syntax. can be nested by repeating the
78 -* subtitle (--): attaches a subtitle to the previous header
79 -* embed (&): embeds a referenced object. can be used to show images or repeat previously defined objects like lists or tables, optionally with a caption.
80 -** &myimg All that remained of the unfortunate blood magic pageant contestants and audience (police photo)
81 -** &$mymacro arg 1|arg 2|arg 3
82 -* break (---): inserts a horizontal rule or other context break; does not end the section. must be followed by newline.
83 -* table cells (+ |): see [>ex.tab table examples].
49 +the first character(s) of every line (the "control sequence") indicates the role of that line. if no control sequence is recognized, the line is treated as a paragraph. the currently supported control sequences are listed below. some control sequences have alternate forms, in order to support modern, readable unicode characters as well as plain ascii text.
50 +
51 +* [*paragraphs] ([`.] [` ¶] [`❡]): a paragraph is a simple block of text. the period control sequence is only necessary if the paragraph text starts with text that would be interpreted as a control sequence otherwise
52 +* newlines [` \\]: inserts a line break into previous paragraph and attaches the following text. mostly useful for poetry or lyrics
53 +* [*section starts] [`#] [`§]: starts a new section. all sections have an associated depth, determined by the number of sequence repetitions (e.g. "###" indicates depth-three"). sections may have headers and IDs; both are optional. IDs, if present, are a sequence of raw-text immediately following the hash marks. if the line has one or more space character followed by styled-text, a header will be attached. the character immediately following the hashes can specify a particular type of section. e.g.:
54 +** [`#] is a simple section break.
55 +** [`#anchor] opens a new section with the ID [`anchor].
56 +** [`# header] opens a new section with the title "header".
57 +** [`#anchor header] opens a new section with both the ID [`anchor] and the title "header".
58 +** [`#>conversation] opens a blockquote section named [`conversation] without a header.
59 +* [*nonprinting sections] ([`^]): sometimes, you'll want to create a namespace without actually adding a visible new section to the document. you can achieve this by creating a [!nonprinting section] and defining resources within it. nonprinting sections can also be used to store comments, notes, or other information that is useful to have in the source file without it becoming a part of the output
60 +** [`#&id mime] opens a new inline object [`id] of type [`mime]. useful for embedding SVGs. the ID and mime type must be specified.
61 +* [*resource] ([`@]): defines a [!resource]. a resource is an file or object that exists outside of the document but which will be included in the document somehow. common examples of resources include images, videos, iframes, or headers/footers. see [>rsrc resources] for more information.
62 +* [*lists] ([`*] [`:]): these are like paragraph nodes, but list nodes that occur next to each other will be arranged so as to show they compose a sequence. depth is determined by the number of stars/colons. like headers, a list entry may have an ID that can be used to refer back to it; it is indicated in the same way. if colons are used, this indicates that the order of the items is signifiant. :-lists and *-lists may be intermixed; however, note than only the last character in the sequence actually controls the depth type.
63 +* [*directives] ([`%]): a directive issues a hint to the renderer in the form of an arbitrary string. directives are normally ignored if they are not supported, but you may cause a warning to be emitted where the directive is not supported with [`%!] or mark a directive critical with [`%!!] so that rendering will entirely fail if it cannot be parsed.
64 +* [*comments] ([`%%]): a comment is a line of text that is simply ignored by the renderer.
65 +* [*asides] ([`!]): indicates text that diverges from the narrative, and can be skipped without interrupting it. think of it like block-level parentheses. asides which follow one another are merged as paragraphs of the same aside, usually represented as a sort of box. if the first line of an aside contains a colon, the stretch of styled-text from the beginning to the aside to the colon will be treated as a "type heading," e.g. "Warning:"
66 +* [*code] ([`~~~]): a line beginning with ~~~ begins or terminates a block of code. code blocks are by default not parsed, but parsing can be activated by preceding the code block with an [`%[*expand]] directive. the opening line should look like one of the below
67 +** [`~~~]
68 +** [`~~~ language] (markdown-style shorthand syntax)
69 +** [`~~~ \[language\] ~~~] (cortav syntax)
70 +** [`~~~ \[language\] #id ~~~]
71 +** [`~~~ title ~~~]
72 +** [`~~~ title \[language\] ~~~]
73 +** [`~~~ \[language\] title ~~~]
74 +** [`~~~ title \[language\] #id ~~~]
75 +*[*reference] (tab): a line beginning with a tab is treated as a "reference." references hold out-of-line metadata for preceding text like links and footnotes. a reference consists of an identifier followed by a colon and an arbitrary number of spaces or tabs, followed by text. whether this text is interpreted as raw-text or styled-text depends on the context in which the reference is used. in encodings without tab characters, two preceding blanks can be used instead.
76 +* [*quotation] ([`<]): a line of the form [`<[$name]> [$quote]] denotes an utterance by [$name].
77 +* [*blockquote] ([`>]): alternate blockquote syntax. can be nested by repeating the [`>] character.
78 +* [*subtitle] ([`--]): attaches a subtitle to the previous header
79 +* [*embed] ([`&]): embeds a referenced object. can be used to show images or repeat previously defined objects like lists or tables, optionally with a caption.
80 +** [`&$[$macro] [$arg1]|[$arg2]|[$argn]…] invokes a block-level macro with the supplied arguments
81 +*** [`&$mymacro arg 1|arg 2|arg 3]
82 +** [`&[$image]] embeds an image or other block-level object. [!image] can be a reference with a url or file path, or it can be an embed section (e.g. for SVG files)
83 +***[`&myimg All that remained of the unfortunate blood magic pageant contestants and audience (police photo)]
84 +** [`&-[$section]] embeds a closed disclosure element. in interactive outputs, this will display as a block [!section] which can be clicked on to view the full contents of the referenced section; in static outputs, it will display as an enclosed box with [$section] as the title text
85 +*** [`&-ex-a Prosecution Exhibit A (GRAPHIC CONTENT)]
86 +** [`&+[$section]] is like the above, but the disclosure element is open by default
87 +* [*horizontal rule] ([`\---]): inserts a horizontal rule or other context break; does not end the section. must be followed by newline. underlines can also be used in place of dashes.
88 +* [*page break] ([`\^^]): for formats that support pagination, like HTML (when printed), indicates that the rest of the current page should be blank. for formats that do not, extra margins will be inserted. does not create a new section
89 +* [*page rule] ([`\^^-]): inserts a page break for formats that support them, and a horizontal rule for formats that do not. does not create a new section
90 +* [*table cells] ([`+ |]): see [>ex.tab table examples].
91 +* [*equations] ([`=]) block-level equations can be inserted with the [`=]
92 +* [*empty lines] (that is, lines consisting of nothing but whitespace) constitute a [!break], which terminates multiline objects that do not have a dedicated termination sequence, for example lists and asides.
84 93
85 94 ## styled text
86 -most blocks contain a sequence of spans. these spans are produced by interpreting a stream of [*styled-text] following the control sequence. styled-text is a sequence of codepoints potentially interspersed with escapes. an escape is formed by an open square bracket [$\[] followed by a [*span control sequence], and arguments for that sequence like more styled-text. escapes can be nested.
95 +most blocks contain a sequence of spans. these spans are produced by interpreting a stream of [*styled-text] following the control sequence. styled-text is a sequence of codepoints potentially interspersed with escapes. an escape is formed by an open square bracket [`\[] followed by a [*span control sequence], and arguments for that sequence like more styled-text. escapes can be nested.
87 96
88 -* strong \[*[!styled-text]\]: causes its text to stand out from the narrative, generally rendered as bold or a brighter color.
89 -* emphatic \[![!styled-text]\]: indicates that its text should be spoken with emphasis, generally rendered as italics
90 -* literal \[$[!styled-text]\]: indicates that its text is a reference to a literal sequence of characters, variable name, or other discrete token. generally rendered in monospace
91 -* strikeout \[~[!styled-text]\]: indicates that its text should be struck through or otherwise indicated for deletion
92 -* insertion \[+[!styled-text]\]: indicates that its text should be indicated as a new addition to the text body.
93 -** consider using a macro definition [$\edit: [~[#1]][+[#2]]] to save typing if you are doing editing work
94 -* link \[>[!ref] [!styled-text]\]: produces a hyperlink or cross-reference denoted by [$ref], which may be either a URL specified with a reference or the name of an object like an image or section elsewhere in the document. the unicode characters [$→] and [$🔗] can also be used instead of [$>] to denote a link.
95 -* footnote \[^[!ref] [!styled-text]\]: annotates the text with a defined footnote
96 -* raw \[\\[!raw-text]\]: causes all characters within to be interpreted literally, without expansion. the only special characters are square brackets, which must have a matching closing bracket
97 +* strong {obj *|styled-text}: causes its text to stand out from the narrative, generally rendered as bold or a brighter color.
98 +* emphatic {obj !|styled-text}: indicates that its text should be spoken with emphasis, generally rendered as italics
99 +* literal {obj `|styled-text}: indicates that its text is a reference to a literal sequence of characters or other discrete token. generally rendered in monospace
100 +* variable {obj $|styled-text}: indicates that its text is a stand-in that will be replaced with what it names. generally rendered in italic monospace, ideally of a different color
101 +* underline {obj _|styled-text}: underlines the text. use sparingly on text intended for webpages -- underlined text [!is] distinct from links, but underlining non-links is still a violation of convention.
102 +* strikeout {obj ~|styled-text}: indicates that its text should be struck through or otherwise indicated for deletion
103 +* insertion {obj +|styled-text}: indicates that its text should be indicated as a new addition to the text body.
104 +** consider using a macro definition [`\edit: [~[#1]][+[#2]]] to save typing if you are doing editing work
105 +* link \[>[!ref] [!styled-text]\]: produces a hyperlink or cross-reference denoted by [$ref], which may be either a URL specified with a reference or the name of an object like an image or section elsewhere in the document. the unicode characters [`→] and [`🔗] can also be used instead of [`>] to denote a link.
106 +* footnote {span ^|ref|[$styled-text]}: annotates the text with a defined footnote. in interactive output media [`\[^citations.qtheo Quantum Theosophy: A Neophyte's Catechism]] will insert a link with the next [`Quantum Theosophy: A Neophyte's Catechism] that, when clicked, causes a footnote to pop up on the screen. for static output media, the text will simply have a superscript integer after it denoting where the footnote is to be found.
107 +* superscript {obj '|[$styled-text]}:
108 +* subscript {obj ,|[$styled-text]}:
109 +* raw \[\\[`raw-text]\]: causes all characters within to be interpreted literally, without expansion. the only special characters are square brackets, which must have a matching closing bracket
97 110 * raw literal \[$\\[!raw-text]\]: shorthand for [\[$[\…]]]
98 -* macro \{[!name] [!arguments]\}: invokes a [>ex.mac macro], specified with a reference
99 -* argument \[#[!var]\]: in macros only, inserts the [$var]-th argument. otherwise, inserts a context variable provided by the renderer.
100 -* raw argument \[##[!var]\]: like above, but does not evaluate [$var].
101 -* term \[&[!name] ([!label])\]: quotes a defined term with a link to its definition
102 -* inline image \[&@[!name]\]: shows a small image or other object inline. the unicode character [$🖼] can also be used instead of [$&@].
103 -
104 -## identifiers
105 -any identifier (including a reference) that is defined within a named section must be referred to from outside that section as [$[!sec].[!obj]], where [$sec] is the ID of the containing section and [$obj] is the ID of the object one wishes to reference.
106 -
107 -## context variables
108 -context variables are provided so that cortav renderers can process templates. certain context variables are provided for by the standard. you can test for the presence of a context variable with the directive [$%[*when] ctx [!var]].
111 +* macro [`\{[!name] [!arguments]\}]: invokes a [>ex.mac macro], specified with a reference
112 +* argument {obj #|var}: in macros only, inserts the [$var]-th argument. otherwise, inserts a context variable provided by the renderer.
113 +* raw argument {obj ##|var}: like above, but does not evaluate [$var].
114 +* term {obj &|name}, {span &|name|[$expansion]}: quotes a defined term with a link to its definition, optionally with a custom expansion of the term (for instance, to expand the first use of an acronym)
115 +* inline image {obj &@|name}: shows a small image or other object inline. the unicode character [`🖼] can also be used instead of [`&@].
116 +* unicode codepoint {obj U+|hex-integer}: inserts an arbitrary UCS codepoint in the output, specified by [$hex-integer]. lowercase [`u] is also legal.
117 +* math mode {obj =|equation}: activates additional transformations on the span to format it as a mathematical equation; e.g. [`*] becomes [`×] and [`/] --> [`÷].
118 +* extension {span %|ext|…}: invokes extension named in [$ext]. [$ext] will usually be an extension name followed by a symbol (often a period) and then an extension-specific directive, although for some simple extensions it may just be the plain extension name. further syntax and semantics depend on the extension. this syntax can also be used to apply formatting specific to certain renderers, such as assigning a CSS class in the [`html] renderer ([`\[%html.myclass my [!styled] text]]).
119 +* critical extension {span %!|ext|…}: like [!extension], but will trigger an error if the requested extension is not available
120 +* extension text {span %:|ext|styled-text}: like [!extension], but when the requested extension is not present, [$styled-text] wlil be emitted as-is. this is a better way to apply CSS classes, as the text will still be visible when rendered to formats other than HTML.
121 +* inline comment {obj %%|...}: ignored. useful for editorial annotations not intended to be part of the rendered product.
122 +
123 + span: [` \[[*[#1]][$[#2]] [#3]\]]
124 + obj: [` \[[*[#1]][$[#2]]\]]
125 +
126 +##ident identifiers
127 +any identifier (including a reference) that is defined within a named section must be referred to from outside that section as [`[!sec].[!obj]], where [$sec] is the ID of the containing section and [$obj] is the ID of the object one wishes to reference.
128 +
129 +##rsrc resources
130 +a [!resource] represents content that is not encoded directly into the source file, but which is embedded by some means in the output. resources can either be [!embedded], in which case they are compiled into the final document itself, or they can be [!linked], in which case the final document only contains a URI or similar tag referencing the resource. not all render backends support both linking and embedding embedding, nor do all backends support all object types (for instance, [`groff] does not support video embedding.)
131 +
132 +a resource definition is begun by line consisting of an [`@] sign and an [>ident identifier]. this line is followed by any number of parameters. a parameter is a line beginning with a single tab, a keyword, a colon, and a then a value. additional lines can be added to a parameter by following it with a line that consists of two tabs followed by the text you wish to add. (this is the same syntax used by references.) a resource definition is terminated by a break, or any line that does not begin with a tab
133 +
134 +a resource definition in use looks like this:
135 +
136 +~~~
137 +this is a demonstration of resources
138 +@smiley
139 + src: link image/webp http://cdn.example.net/img/smile.webp
140 + link image/png file:img/smile.png
141 + embed image/gif file img/smile.gif
142 + desc: the Smiling Man would like to see you in his office
143 +here is the resource in span context [&smiley]
144 +and here it is in block context:
145 +&smiley
146 +~~~
147 +
148 +rendered as HTML, this might produce the following:
149 +
150 +~~~
151 +<style>
152 + .res-smiley {
153 + content: image-set(
154 + url(http://cdn.example.net/img/smile.webp) type(image/webp),
155 + url(img/smile.png) type(image/png),
156 + url(data:image/gif;base64,/* … */) type(image/gif)
157 + ); /* this will actually be repeated with a -webkit- prefix */
158 + }
159 +</style>
160 +<p>this is a demonstration of resources</p>
161 +<p>here is the resource in span context: <span class="res-smiley"></span></p>
162 +<p>and here it is in block context:</p>
163 +<div class=".res-smiley"></div>
164 +~~~
165 +
166 +note that empty elements with CSS classes are used in the output, to avoid repeating long image definitions (especially base64 inline encoded ones!)
167 +
168 +### supported parameters
169 +* [`src] (all): specifies where to find the file, what it is, and how to embed it. each line of [`src] should consist of three whitespace-separated words: embed method, MIME type, and URI.
170 +** embed methods
171 +*** [`local]: loads the resource at build time and embeds it into the output file. not all implementations may allow loading remote network resources at build time.
172 +*** [`remote]: only embeds a reference to the location of the resource. use this for e.g. live iframes, dynamic images, or images hosted by a CDN.
173 +*** [`auto]: embeds a reference in file formats where that's practical, and use a remote reference otherwise.
174 +** MIME types: which file types are supported depends on the individual implementation and renderer backend; additionally, extensions can add support for extra types. MIME-types that have no available handler will, where possible, result in an attachment that can be extracted by the user, usually by clicking on a link. however, the following should be usable with all compliant implementations
175 +*** [`image/*] (graphical outputs only)
176 +*** [`video/*] (interactive outputs only)
177 +*** [`image/svg+xml] is handled specially for HTML files, and may or may not be compatible with other renderer backends.
178 +*** [`font/*] can be used with the HTML backend to reference a web font
179 +*** [`font/woff2] can be used with the HTML backend to reference a web font
180 +*** [`text/plain] (will be inserted as a preformatted text block)
181 +*** [`text/css] (can be used when producing HTML files to link in an extra stylesheet, either by embedding it or referencing it from the header)
182 +*** [`text/x-cortav] (will be parsed and inserted as a formatted text block; context variables can be passed to the file with [`ctx.[$var]] parameters)
183 +*** any MIME-type that matches the type of file being generated by the renderer can be used to include a block of data that will be passed directly to the renderer.
184 +** URI types: additional URI types can be added by extensions or different implementations, but every compliant implementation must support these URIs.
185 +*** [`http], [`https]: accesses resources over HTTP. add a [`file] fallback if possible for the benefit of renderers/viewers that do not have internet access abilities.
186 +*** [`file]: references local files. absolute paths should begin [`file:/]; the slash should be omitted for relative paths. note that this doesn't have quite the same meaning as in HTML -- [`file] can (and usually should be) used with HTML outputs to refer to resources that reside on the same server. a cortav URI of [`file:/etc/passwd] will actually result in the link [`/etc/passwd], not [`file:///etc/passwd] when converted to HTML. generally, you only should use [`http] when you're referring to a resource that exists on a different domain.
187 +*** [`name]: a special URI used generally for referencing resources that are already installed on a target system and do not need to be embedded or linked, the name and type are enough for a renderer on another machine to locate the correct resource. this is useful mostly for [>fonts fonts], where it's more typical to refer to fonts that are installed on your system rather than providing paths to font files.
188 +*** [`gemini]: accesses resources over the gemini protocol. currently you should really only use this for [`local] resources unless you're using the gemtext renderer backend, since nothing but gemini browsers are liable to support this protocol.
189 +* [`desc]: supplies a narrative description of the resources, for use as an "alt-text" when the image cannot be loaded and for screenreaders.
190 +* [`detail]: supplies extra narrative commentary that is displayed contextually, e.g. when the user hovers her mouse cursor over the embedded object.
191 +
192 +note that in certain cases, full MIME types do not need to be used. say you're defining a font with the [`name] URI -- you can't necessary know what file type the system fonts on another computer are going to be. in this case, you can just write [`font] instead of [`font/ttf] or [`font/woff2] or similar. all cortav needs to know in this case is what abstract kind of object you're referencing.
193 +
194 +
195 +##ctxvar context variables
196 +context variables are provided so that cortav renderers can process templates. certain context variables are provided for by the standard. you can test for the presence of a context variable with the directive [`%[*when] ctx [$var]]. context variables are accessed with the [` \[#[$name]\]] span.
109 197
110 198 * {def cortav.file} the name of the file currently being rendered
111 199 * {def cortav.path} the absolute path of the file currently being rendered
112 -* {def cortav.time} the current system time in the form [$[#cortav.time]]
113 -* {def cortav.date} the current system date in the form [$[#cortav.date]]
114 -* {def cortav.datetime} the current system date and time represented in the locale or system-standard manner (e.g. [$[#cortav.datetime]])
200 +* {def cortav.time} the current system time in the form [`[#cortav.time]]
201 +* {def cortav.date} the current system date in the form [`[#cortav.date]]
202 +* {def cortav.datetime} the current system date and time represented in the locale or system-standard manner (e.g. [`[#cortav.datetime]])
115 203 * {def cortav.page} the number of the page currently being rendered
116 204 * {def cortav.id} the identifier of the renderer
117 205 * {def cortav.hash} the SHA3 hash of the source file being rendered
118 206 def: [*[#1]]:
119 207
120 -on systems with environment variables, these may be accessed as context variables by prefixing their name with [$env.].
208 +on systems with environment variables, these may be accessed as context variables by prefixing their name with [`env.].
121 209
122 210 different renderers may provide context in different ways, such as from command line options or a context file. any predefined variables should carry an appropriate prefix to prevent conflation.
123 211
124 -## directives
125 - d: [$%[*[##1]]]
126 -* {d author} encodes document authorship
212 +##fonts fonts
213 +for output backends that support font specification, cortav provides a sophisticated font management system by means of the [!font stack].
214 +
215 +when a document parse begins, the font stack is empty (unless a default font has already been loaded by an intent file).
216 +when the font stack is empty, cortav does not include font specifications in its output, and thus will use whatever the default of the various rendering programs is.
217 +
218 +to use fonts, we first have to define the fonts as [>rsrc resources].
219 +
220 +~~~cortav
221 +%% first, we create a new section to namespace the fonts
222 +#^fonts
223 +%% we then define each font as a resource
224 +@serif
225 + src: auto font name:Alegreya
226 + embed font/ttf file:project-fonts/alegreya.ttf
227 + link font/woff2 file:/assets/font/alegreya.woff2
228 + auto font name:Times New Roman
229 +@sans
230 + src: link font name:Alegreya Sans
231 + link font name:Open Sans
232 + link font name:sans-serif
233 +~~~
234 +
235 +here we have defined two font families, [`fonts.serif] and [`fonts.sans]. each contains a list of references to fonts which will be tried in order. for example, this could be translated into the following CSS:
236 +
237 +~~~css
238 +@font-face {
239 + font-family: "fontdef-serif";
240 + src: local("Alegreya"),
241 + url("data:font/ttf;base64,…") format("font/ttf"),
242 + url("/assets/font/alegreya.woff2") format("font/woff2"),
243 + local("Times New Roman");
244 +}
245 +@font-face {
246 + font-family: "fontdef-sans";
247 + src: local("Alegreya Sans"),
248 + local("Open Sans"),
249 + local("sans-serif");
250 +}
251 +~~~
252 +
253 +there are two things that aren't super clear from the CSS, however. notice how we used [`auto] on a couple of those specs? this means it's up to the renderer to decide whether to link or embed the font. for html, a font specified by name can't really be embedded, but for some file formats, it can be. [`auto] lets us produce valid HTML while still taking advantage of font embedding in other formats.
254 +
255 +now that we have our font families defined, we can use their identifiers with the [`%[*font]] directive to control the font stack. the first thing we need to do is push a new font context. there's two ways we can do this:
256 + fnd: [`%[*font] [#1]]
257 +* {fnd dup} will create a copy of the current font context, allowing us to make some changes and then revert later with the {fnd pop} command. this isn't useful in our case, however, because right now the stack is empty; there's nothing to duplicate.
258 +* {fnd new} will create a brand new empty context for us to work with and push it to the stack. this can also be used to temporarily revert to the system default fonts, and then switch back with {fnd pop}.
259 +* {fnd set} changes one or more entries in the current font context. it can take a space-separated list of arguments in the form [`[$entry]=[$font-id]]. the supported entries are:
260 +** [`body]: the fallback font. if only this is set in a given font context, it will be used for everything
261 +** [`paragraph]: the font used for normal paragraphs
262 +** [`header]: the font used in headers
263 +** [`subtitle]: the font used in subtitles
264 +** [`list]: the font used in lists
265 +** [`table]: the font used in tables
266 +** [`caption]: the font used for captions
267 +* {fnd pop} removes the top context from the font stack.
268 +
269 +note that extensions may consult the font context for their entries specific to them. for instance, [>toc toc] checks for [`toc] before falling back to [`body] and then the default font.
270 +
271 +these commands are enough to give us a very flexible setup. consider the following:
272 +
273 +~~~cortav
274 +%% let's pretend we've also defined the fonts 'title', 'cursive', and 'thin'
275 +
276 +%font new
277 +%font set body=sans header=serif
278 +%font dup
279 +%font header=title
280 +# lorem ipsum dolor
281 +%font pop
282 +
283 +%% we've now set up a default font context, created a new context for the title of the
284 +%% document, and then popped it back off after the title was inserted so that our
285 +%% first font context is active again. everything after that last '%font pop' will
286 +%% be printed in sans, except for headers, which will be printed in 'serif'
287 +
288 +lorem ipsum dolor sit amet, sed consectetur apiscing elit…
289 +
290 +%font dup
291 +%font set body=cursive
292 +> sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
293 +> Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
294 +%font pop
295 +
296 +%% above we created a blockquote whose text is printed in a cursive font; afterwards,
297 +%% we simply remove this new context—
298 +
299 +and everything is back the way it was at "lorem ipsum"
300 +
301 +%% the font mechanism is at its most powerful when used with multiline macros:
302 +
303 + cursive-quote: %font dup
304 + %font set body=cursive
305 + > [#1]
306 + %font pop
307 +
308 +%% now, whenever we want a block with a cursive body, we can simply invoke
309 +
310 +&$cursive-quote Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident
311 +
312 +%% without affecting the overall font context. in fact, since 'cursive-quote' creates
313 +%% its context using 'dup', it would import all font specifications besides 'body'
314 +%% from the environment it is invoked in
315 +~~~
316 +
317 +##dir directives
318 + d: [`%[*[##1]]]
319 +* {d author} encodes document authorship. multiple author directives can be issued to add additional coauthors
127 320 * {d cols} specifies the number of columns the next object should be rendered with
128 321 * {d include} transcludes another file
322 +* {d import} reads in the contents of another file as an embeddable section
129 323 * {d quote} transcludes another file, without expanding the text except for paragraphs
130 324 * {d embed}, where possible, embeds another file as an object within the current one. in HTML this could be accomplished with e.g. an iframe.
131 325 * {d expand} causes the next object (usually a code block) to be fully expanded when it would otherwise not be
132 -* {d pragma} supplies semantic data about author intent, the kind of information document contains and hints about how it should be displayed to the user. think of them like offhand remarks to the renderer -- there's no guarantee that it'll pay any attention, but if it does, your document will look better. pragmas have no scope; they affect the entire document. the pragma function exists primarily as a means to allow parameters that would normally need to be specified on e.g. the command line to be encoded in the document instead in a way that multiple implementations can understand. a few standard pragmas are defined.
326 +* {d font} controls the font stack, for outputs that support changing fonts. see [>fonts fonts] for more information.
327 +* {d lang} changes the current language, which is used by extensions to e.g. control typographical conventions, and may be encoded into the output by certain renderers (e.g. HTML). note that quotes and blockquotes can be set to a separate language with a simpler syntax. the language should be notated using IETF language tags
328 +** {d lang is x-ranuir-CR8} sets the current language to Ranuir as spoken in the Central Worlds, written in Corran and encoded using UTF-8. this might be used at the top of a document to set its primary language.
329 +** {d lang push gsw-u-sd-chzh} temporarily switches to Zürich German, e.g. to quote a German passage in an otherwise Ranuir document
330 +** {d lang sec en-US} switches to American English for the duration of a section. does not affect the language stack.
331 +** {d lang pop} drops the current language off the language stack, returning to whatever was pushed or set before it. this would be used, for instance, at the end of a passage
332 +* {d pragma} supplies semantic data about author intent, the kind of information the document contains and hints about how it should be displayed to the user. think of them like offhand remarks to the renderer -- there's no guarantee that it'll pay any attention, but if it does, your document will look better. pragmas have no scope; they affect the entire document. the pragma function exists primarily as a means to allow parameters that would normally need to be specified on e.g. the command line to be encoded in the document instead in a way that multiple implementations can understand. a few standard pragmas are defined.
133 333 ** {d pragma layout} gives a hint on how the document should be layed out. the first hint that is understood will be applied; all others will be discarded. standard hints include:
134 -*** essay
135 -*** narrative
136 -*** screenplay: uses asides to denote actions, quotes for dialogue
137 -*** stageplay: uses asides to denote actions, quotes for dialogue
138 -*** manual
139 -*** glossary
140 -*** news
334 +*** [`essay]
335 +*** [`narrative]
336 +*** [`screenplay]: uses asides to denote actions, quotes for dialogue
337 +*** [`stageplay]: uses asides to denote actions, quotes for dialogue
338 +*** [`manual]
339 +*** [`glossary]
340 +*** [`news]
341 +*** [`book]: section depths 1-3 gain additional semantics
342 +***: [*part]: the section gets a page to itself to announce the beginning of a new part or appendix
343 +***: [*chapter]: the section is preceded by a page break
344 +***: [*heading]: the section can occur on the same page as text and headings from other sections
141 345 ** {d pragma accent} specifies an accent hue (in degrees around the color wheel) for renderers which support colorized output
142 346 ** {d pragma accent-spread} is a factor that controls the "spread" of hues used in the document. if 0, only the accent color will be used; if larger, other hues will be used in addition to the primary accent color.
143 -** {d pragma dark-on-light on|off} controls whether the color scheme used should be light-on-dark or dark-on-light
347 +** {d pragma dark-on-light on\|off} controls whether the color scheme used should be light-on-dark or dark-on-light
144 348 ** {d pragma page-width} indicates how wide the pages should be
349 +** {d pragma title-page} specifies a section to use as a title page, for renderer backends that support pagination
145 350
146 -! note on pragmas: particularly when working with collections of documents, you should not keep formatting metadata in the documents themselves! the best thing to do is to have a makefile for compiling the documents using whatever tools you want to support, and encoding the rendering options in this file (for the reference implementation this currently means as command line arguments, but eventually it will support intent files as well) so they can all be changed in one place; pragmas should instead be used for per-document [*overrides] of default settings.
351 +! note on pragmata: particularly when working with collections of documents, you should not keep formatting metadata in the documents themselves! the best thing to do is to have a makefile for compiling the documents using whatever tools you want to support, and encoding the rendering options in this file (for the reference implementation this currently means as command line arguments, but eventually it will support intent files as well) so they can all be changed in one place; pragmas should instead be used for per-document [*overrides] of default settings.
147 352 ! a workaround for the lack of intent files in the reference implementation is to have a single pseudo-stylesheet that contains only {d pragma} statements, and then import this file from each individual source file using the {d include} directive. this is suboptimal and recommended only when you need to ensure compatibility between different implementations.
148 353 ! when creating HTML files, an even better alternative may be to turn off style generation entirely and link in an external, hand-written CSS stylesheet. this is generally the way you should compile sources for existing websites if you aren't going to write your own extension.
149 354
150 355 ##ex examples
151 356
152 357 ~~~ blockquotes #bq [cortav] ~~~
153 358 the following excerpts of text were recovered from a partially erased hard drive found in the Hawthorne manor in the weeks after the Incident. context is unknown.
................................................................................
185 390
186 391 +:english :| honor |
187 392 +:ranuir :| tef |
188 393 +:zia ţai :| pang |
189 394 +:thalishte:| mbecheve |
190 395 ~~~
191 396
192 -## extensions
397 +##extns extensions
193 398 the cortav specification also specifies a number of extensions that do not have to be supported for a renderer to be compliant. the extension mechanism supports the following directives.
194 399
195 400 * inhibits: prevents an extension from being used even where available
196 401 * uses: turns on an extension that is not specified by the user operating the renderer (e.g. on the command line)
197 402 * needs: causes rendering to fail with an error if the extensions are not available
198 403
199 -where possible, instead of [$needs x y z], the directive [$when has-ext x y z] should be used instead. this causes the next section to be rendered only if the named extensions are available. [$unless has-ext x y z] can be used to provide an alternative format.
404 +where possible, instead of [`needs [$x y z]], the directive [`when has-ext [$x y z]] should be used instead. this causes the next section to be rendered only if the named extensions are available. [`unless has-ext [$x y z]] can be used to provide an alternative format.
200 405
201 406 extensions are mainly interacted with through directives. all extension directives must be prefixed with the name of the extension.
202 407
203 -### toc
204 -sections that have a title will be included in the table of contents. the table of contents is by default inserted at the break between the first level-1 section and the section immediately following it. you may instead place the directive [$toc] where you wish the TOC to be inserted, or suppress it entirely with [$inhibits toc]. note that some renderers may not display the TOC as part of the document itself.
408 +the reference implementation seeks to support all standardized extensions. it's not quite there yet, however.
409 +
410 +###toc toc
411 +sections that have a title will be included in the table of contents. the table of contents is by default inserted at the break between the first level-1 section and the section immediately following it. you may instead place the directive [`toc] where you wish the TOC to be inserted, or suppress it entirely with [`inhibits toc]. note that some renderers may not display the TOC as part of the document itself.
205 412
206 413 toc provides the directives:
207 414
208 -* [$%[*toc]]: insert a table of contents in the specified position. this can be used more than once, but doing so may have confusing, incorrect, or nonsensical results under some renderers, and some may just ignore the directive entirely
209 -* [$%[*toc] mark [!styled-text]]: inserts a TOC entry with the label [!styled-text] pointing to the current location. this can be used to e.g. mark noteworthy images, instances of long quotes or literal blocks, or functions inside an expanded code block.
210 -* [$%[*toc] name [!id styled-text]]: like [$%[*toc] mark] but allows an additional [!id] parameter which specifies the ID the renderer will assign to an anchor element. this is not meaningful for all renderers and when it is, it is up to the renderer to decide what it means.
211 -** the [*html] render backend interprets [!id] as the [$id] element for the anchor tag
212 -** the [*groff] render backend ignores [!id]
213 -
214 -### smart-quotes
215 -a cortav renderer may automatically translate punctuation marks to other punctuation marks depending on their context.
216 -
217 -### hilite
218 -code can be highlighted according to the formal language it is written in.
219 -
220 -### lua
415 +* [`%[*toc]]: insert a table of contents in the specified position. this can be used more than once, but doing so may have confusing, incorrect, or nonsensical results under some renderers, and some may just ignore the directive entirely
416 +* [`%[*toc] mark [$styled-text]]: inserts a TOC entry with the label [$styled-text] pointing to the current location. this can be used to e.g. mark noteworthy images, instances of long quotes or literal blocks, or functions inside an expanded code block.
417 +* [`%[*toc] name [$id styled-text]]: like [`%[*toc] mark] but allows an additional [$id] parameter which specifies the ID the renderer will assign to an anchor element. this is not meaningful for all renderers and when it is, it is up to the renderer to decide what it means.
418 +** the [*html] render backend interprets [$id] as the [`id] element for the anchor tag
419 +** the [*groff] render backend ignores [$id]
420 +
421 +###tsmog transmogrify
422 +a cortav renderer may automatically translate punctuation marks or symbol sequences to superior representations depending on their context. to be compliant this extension should implement, at minimum:
423 +* smart quotes (with consideration for the typographical conventions languages like German or Spanish)
424 +** {dir.d transmogrify|language [$lang]} can be used to explicitly set the language; otherwise, it must be determined from the value of {dir.d pragma|lang}. if this is not present, implementations may fall back on their own methods for determining the language in use, such as command-line flags.
425 +* multigraph to glyph conversion, including at least:
426 +** [`\--] --> "—"
427 +** [`\-->] --> "→"
428 +** [`\<--] --> "←"
429 +
430 +an escape character before any of the sequence characters should prevent the sequence from being rendered. raw nodes (that is, [`\[\…\]] and [`\[`\…\]]) should not be scanned for transmogrification, nor should the contents of code blocks unless marked with the [`%[*expand]] directive
431 +
432 +transmogrification shall only take place after all other parsing steps are completed.
433 +
434 +###hilite hilite
435 +code can be highlighted according to the formal language it is written in. a compliant hilite implementation must implement basic keyword, symbol, comment, pragma, and literal highlighing for the following formal languages.
436 +* C
437 +* [>lua Lua]
438 +* [>html HTML]
439 +* [>scheme Scheme]
440 +* [>terra Terra]
441 +* [>libconfig libconfig]
442 +
443 + lua: https://lua.org
444 + scheme: https://call-cc.org
445 + terra: https://terralang.org
446 + html: https://dev.w3.org/html5/spec-LC/
447 + libconfig: http://hyperrealm.github.io/libconfig/
448 +
449 +the highlighter should make use of semantic HTML tags like [`<var>] where possible.
450 +
451 +###lua lua
221 452 renderers with a lua interpreter available can evaluate lua code:
222 -* [$%lua use [!file]]: evaluates [$file] and makes its definitions available
223 -* [$\[%lua raw [!script]\]]: evaluates [$script] and emits the string it returns (if any) in raw span context.
224 -* [$\[%lua exp [!script]\]]: evaluates [$script] and emits the string it returns (if any) in expanded span context.
225 -* [$%lua raw [!script]]: evaluates [$script] and emits the string array it returns (if any) in raw block context.
226 -* [$%lua exp [!script]]: evaluates [$script] and emits the string array it returns (if any) in expanded block context.
453 +* [`%lua use [!file]]: evaluates [$file] and makes its definitions available
454 +* [`\[%lua raw [!script]\]]: evaluates [$script] and emits the string it returns (if any) in raw span context.
455 +* [` \[%lua exp [!script]\]]: evaluates [$script] and emits the string it returns (if any) in expanded span context.
456 +* [`%lua raw [!script]]: evaluates [$script] and emits the string array it returns (if any) in raw block context.
457 +* [`%lua exp [!script]]: evaluates [$script] and emits the string array it returns (if any) in expanded block context.
227 458
228 -the interpreter should provide a [$cortav] table with the objects:
459 +the interpreter should provide a [`cortav] table with the objects:
229 460 * ctx: contains context variables
230 461
231 462 used files should return a table with the following members
232 463 * macros: an array of functions that return strings or arrays of strings when invoked. these will be injected into the global macro namespace.
233 464
234 -### ts
465 +###ts ts
235 466 the [*ts] extension allows documents to be marked up for basic classification constraints and automatically redacted. if you are seriously relying on ts for confidentiality, make damn sure you start the file with [$%[*requires] ts], so that rendering will fail with an error if the extension isn't supported.
236 467
237 468 ts enables the directives:
238 -* [$ts class [!scope] [!level] (styled-text)]: indicates a classification level for either the while document (scope [!doc]) or the next section (scope [!sec]). if the ts level is below [$level], the section will be redacted or rendering will fail with an error, as appropriate. if styled-text is included, this will be treated as the name of the classification level.
239 -* [$ts word [!scope] [!word] (styled-text)]: indicates a codeword clearance that must be present for the text to render. if styled-text is present, this will be used to render the name of the codeword instead of [$word].
240 -* [$when ts level [!level]]
241 -* [$when ts word [!word]]
469 +* [`%[*ts] class [$scope level] ([$styled-text])]: indicates a classification level for either the while document (scope [$doc]) or the next section (scope [$sec]). if the ts level is below [$level], the section will be redacted or rendering will fail with an error, as appropriate. if styled-text is included, this will be treated as the name of the classification level.
470 +* [`%[*ts] word [$scope word] ([$styled-text])]: indicates a codeword clearance that must be present for the text to render. if styled-text is present, this will be used to render the name of the codeword instead of [$word].
471 +* [`%[*when] ts level [$level]]
472 +* [`%[*when] ts word [$word]]
242 473
243 474 ts enables the spans:
244 -* [$\[🔒#[!level] [!styled-text]\]]: redacts the span if the security level is below that specified.
245 -* [$\[🔒.[!word] [!styled-text]\]]: redacts the span if the specified codeword clearance is not enabled.
246 -(the padlock emoji is shorthand for [$%ts].)
475 +* [`\[🔒#[!level] [$styled-text]\]]: redacts the span if the security level is below that specified.
476 +* [`\[🔒.[!word] [$styled-text]\]]: redacts the span if the specified codeword clearance is not enabled.
477 +(the padlock emoji is shorthand for [`%[*ts]].)
247 478
248 479 ts redacts spans securely; that is, they are simply replaced with an indicator that they have been redacted, without visually leaking the length of the redacted text.
249 480
250 481 ~~~#ts-example example [cortav] ~~~
251 482 %ts word doc sorrowful-pines SORROWFUL PINES
252 483
253 484 # intercept R1440 TCT S3
................................................................................
266 497 <B> Hyacinth, I told you not to contact me without—
267 498 <A, shouting> god DAMMIT woman I am trying to SAVE your worthless skin
268 499 <B> Hyacinth! your Godforsaken scrambler!
269 500 <A> …oh, [!fuck].
270 501 (signal lost)
271 502 ~~~
272 503
273 -# reference implementation
274 -the cortav standard is implemented in [$cortav.lua], found in this repository. only the way [$cortav.lua] interprets the cortav language is defined as a reference implementation; other behaviors are simply how [$cortav.lua] implements the specification and may be copied, ignored, tweaked, violently assaulted, or used as inspiration by a compliant parser.
504 +#refimpl reference implementation
505 +the cortav standard is implemented in [`cortav.lua], found in this repository. only the way [`cortav.lua] interprets the cortav language is defined as a reference implementation; other behaviors are simply how [`cortav.lua] implements the specification and may be copied, ignored, tweaked, violently assaulted, or used as inspiration by a compliant parser.
275 506
276 -the reference implementation can be used both as a lua library and from the command line. [$cortav.lua] contains the parser and renderers, [$ext/*] contain various extensions, [$sirsem.lua] contains utility functions, and [$cli.lua] contains the CLI driver.
507 +the reference implementation can be used both as a lua library and from the command line. [`cortav.lua] contains the parser and renderers, [`ext/*] contain various extensions, [`sirsem.lua] contains utility functions, and [`cli.lua] contains the CLI driver.
277 508
278 -## lua library
509 +##refimpl-lib lua library
279 510 there are various ways to use cortav from a lua script; the simplest however is probably to precompile your script with luac and link in the necessary components of the implementation. for instance, say we have the following program
280 511
281 512 ~~~ stdin2html.lua [lua] ~~~
282 513 local ct = require 'cortav'
283 514 local mode = {}
284 515 local doc = ct.parse(io.stdin, {file = '(stdin)'}, mode)
285 516 doc.stage = {
................................................................................
292 523
293 524 and the only extension we need is the table-of-contents extension. our script can be translated into a self-contained lua bytecode blob with the following command
294 525
295 526 ~~~
296 527 $ luac -s -o stdin2html.lc $cortav_repo/{sirsem,cortav,ext/toc}.lua stdin2html.lua
297 528 ~~~
298 529
299 -and can then be operated with the command [$lua stdin2html.lc], with no further need for the cortav repository files. note that the order of the [$luac] command is important! [$sirsem.lua] must come first, followed by [$cortav.lua], followed by any extensions. your driver script (i.e. the script with the entry point into the application) should always come last.
530 +and can then be operated with the command [`lua stdin2html.lc], with no further need for the cortav repository files. note that the order of the [`luac] command is important! [`sirsem.lua] must come first, followed by [`cortav.lua], followed by any extensions. your driver script (i.e. the script with the entry point into the application) should always come last.
300 531
301 -### building custom tools
532 +###refimpl-tools building custom tools
302 533 generally, most existing file-format conversion tools (cmark, pandoc, and so on) have a crucial limitation: they hardcode specific assumptions like document structure. this means that the files they output are generally not suitable as-is for the users' purposes, and require further munging, usually by hateful shell or perl scripts. some tools do provide libraries end users to use as a basis for designing their own tools, but these are often limited, and in any case the user ends up having to write their own (non-standard) driver. it's no surprise that very few people end up doing this.
303 534
304 -[$cortav.lua]'s design lends itself to a more elegant solution. one can of course write their own driver using [$cortav] as a library, but most of the time when you're compiling document sources, you just want a binary you can run from the command line or a makefile. with [$cortav.lua], you can extend its capabilities easily while keeping the same driver.
535 +[`cortav.lua]'s design lends itself to a more elegant solution. one can of course write their own driver using [`cortav] as a library, but most of the time when you're compiling document sources, you just want a binary you can run from the command line or a makefile. with [`cortav.lua], you can extend its capabilities easily while keeping the same driver.
305 536
306 -in the [$cortav] spec, extensions are mostly intended to give different implementations the ability to offer extra capabilities, but the reference implementation uses an extension architecture that makes it easy to write and add your own. for each type of new behavior you want to implement, just create a new extension and list it on the make command line:
537 +in the [`cortav] spec, extensions are mostly intended to give different implementations the ability to offer extra capabilities, but the reference implementation uses an extension architecture that makes it easy to write and add your own. for each type of new behavior you want to implement, just create a new extension and list it on the make command line:
307 538
308 539 ~~~
309 540 $ nvim ~/dev/my-cortav-exts/imperial-edict.lua
310 541 $ make cortav extens+=$HOME/dev/my-cortav-exts/*.lua
311 542 ~~~
312 543
313 -the cortav binary this produces will have all the extra capabilities you personally need, without any need to fork [$cortav.lua] itself or even touch the repository.
544 +the cortav binary this produces will have all the extra capabilities you personally need, without any need to fork [`cortav.lua] itself or even touch the repository.
314 545
315 -there's no reason [$cortav.lua] shouldn't be able to load extensions at runtime as well; i just haven't implemented this behavior yet. it probably would only take a few extra lines of code tho.
546 +there's no reason [`cortav.lua] shouldn't be able to load extensions at runtime as well; i just haven't implemented this behavior yet. it probably would only take a few extra lines of code tho.
316 547
317 -i will eventually document the extension API, but for now, look at [$ext/toc.lua] for a simple example of how to register an extension.
548 +i will eventually document the extension API, but for now, look at [`ext/toc.lua] for a simple example of how to register an extension.
318 549
319 -## command line driver
320 -the [$cortav.lua] command line driver can be run from the repository directory with the command [$lua ./cli.lua], or by first compiling it into a bytecode form that links in all its dependencies. this is the preferred method for installation, as it produces a self-contained executable which loads more quickly, but running the driver in script form may be desirable for development or debugging.
550 +##refimpl-cli command line driver
551 +the [$cortav.lua] command line driver can be run from the repository directory with the command [`lua ./cli.lua], or by first compiling it into a bytecode form that links in all its dependencies. this is the preferred method for installation, as it produces a self-contained executable which loads more quickly, but running the driver in script form may be desirable for development or debugging.
321 552
322 -the repository contains a GNU makefile to automate compilation of the reference implementation on unix-like OSes. simply run [$$ make cortav] or [$$ gmake cortav] from the repository root to produce a self-contained bytecode executable that can be installed anywhere on your filesystem, with no dependencies other than the lua interpreter.
553 +the repository contains a GNU makefile to automate compilation of the reference implementation on unix-like OSes. simply run [`$ make cortav] or [`$ gmake cortav] from the repository root to produce a self-contained bytecode executable that can be installed anywhere on your filesystem, with no dependencies other than the lua interpreter.
323 554
324 -! note that the makefile strips debugging symbols to save space, so running [$cli.lua] directly as a script may be helpful if you encounter errors and need stacktraces or other debugging information.
555 +! note that the makefile strips debugging symbols to save space, so running [`cli.lua] directly as a script may be helpful if you encounter errors and need stacktraces or other debugging information.
325 556
326 -henceforth it will be assumed that you have produced the [$cortav] executable and placed it somewhere in your [$$PATH]; if you are instead running [$cortav.lua] directly as an interpreted script, you'll need to replace [$$ cortav] with [$$ lua ./cli.lua] in incantations.
557 +henceforth it will be assumed that you have produced the [`cortav] executable and placed it somewhere in your [$$PATH]; if you are instead running [`cortav.lua] directly as an interpreted script, you'll need to replace [`$ cortav] with [`$ lua ./cli.lua] in incantations.
327 558
328 -when run without commands, [$cortav.lua] will read input from standard input and write to standard output. alternately, a source file can be given as an argument. to write to a specific file instead of the standard output stream, use the [$-o [!file]] flag.
559 +when run without commands, [`cortav.lua] will read input from standard input and write to standard output. alternately, a source file can be given as an argument. to write to a specific file instead of the standard output stream, use the [`-o [!file]] flag.
329 560
330 561 ~~~
331 562 $ cortav readme.ct -o readme.html
332 563 # reads from readme.ct, writes to readme.html
333 564 $ cortav -o readme.html
334 565 # reads from standard input, writes to readme.html
335 566 $ cortav readme.ct
336 567 # reads from readme.ct, writes to standard output
337 568 ~~~
338 569
339 -### switches
340 -[$cortav.lua] offers various switches to control its behavior.
570 +###refimpl-build building
571 +the command line driver is built and installed with a GNU [$make] script. this script accepts the variables shown below with their default values:
572 ++ prefix | [`[$$HOME]/.local] | the path under which the package will be installed
573 ++ build | [`build] | the directory where generated objects will be placed; useful for out-of-tree builds
574 ++ bin-prefix | [`[$$prefix]/bin] | directory to install the executables to"
575 ++ default-format-flags | [`-m html:width 35em] | a list of flags that will be passed by the viewer script to [`cortav] when generating a html fille
576 +
577 +the following targets are supplied to automate the build:
578 +* [`install] builds everything, installs the executable and the viewer script to [$$bin_prefix], and registers the viewer script with XDG
579 +* [`excise] deletes everything installed and deregisters the file handlers (note that the same variables must be passed to [`exicse] as were passed to [`install]!)
580 +* [`clean] deletes build artifacts from the [$$build] directory like it was never there
581 +* [`wipe] is equivalent to [`$ make excise && make clean]
582 +
583 +###refimpl-switches switches
584 +[`cortav.lua] offers various switches to control its behavior.
341 585 + long + short + function +
342 -| [$--out [!file]] :|:[$-o]:| sets the output file (default stdout) |
343 -| [$--log [!file]] :|:[$-l]:| sets the log file (default stderr) |
344 -| [$--define [!var] [!val]] :|:[$-d]:| sets the context variable [$var] to [$val] |
345 -| [$--mode-set [!mode]] :|:[$-y]:| activates the [>refimpl-mode mode] with ID [!mode]
346 -| [$--mode-clear [!mode]] :|:[$-n]:| disables the mode with ID [!mode] |
347 -| [$--mode [!id] [!val]] :|:[$-m]:| configures mode [!id] with the value [!val] |
348 -| [$--mode-set-weak [!mode]] :|:[$-Y]:| activates the [>refimpl-mode mode] with ID [!mode] if the source file does not specify otherwise
349 -| [$--mode-clear-weak [!mode]] :|:[$-N]:| disables the mode with ID [!mode] if the source file does not specify otherwise
350 -| [$--mode-weak [!id] [!val]] :|:[$-M]:| configures mode [!id] with the value [!val] if the source file does not specify otherwise
351 -| [$--help] :|:[$-h]:| display online help |
352 -| [$--version] :|:[$-V]:| display the interpreter version |
586 +| [`--out [!file]] :|:[`-o]:| sets the output file (default stdout) |
587 +| [`--log [!file]] :|:[`-l]:| sets the log file (default stderr) |
588 +| [`--define [!var] [!val]] :|:[`-d]:| sets the context variable [$var] to [$val] |
589 +| [`--mode-set [!mode]] :|:[`-y]:| activates the [>refimpl-mode mode] with ID [!mode]
590 +| [`--mode-clear [!mode]] :|:[`-n]:| disables the mode with ID [!mode] |
591 +| [`--mode [!id] [!val]] :|:[`-m]:| configures mode [!id] with the value [!val] |
592 +| [`--mode-set-weak [!mode]] :|:[`-Y]:| activates the [>refimpl-mode mode] with ID [!mode] if the source file does not specify otherwise
593 +| [`--mode-clear-weak [!mode]] :|:[`-N]:| disables the mode with ID [$mode] if the source file does not specify otherwise
594 +| [`--mode-weak [!id] [!val]] :|:[`-M]:| configures mode [$id] with the value [$val] if the source file does not specify otherwise
595 +| [`--help] :|:[`-h]:| display online help |
596 +| [`--version] :|:[`-V]:| display the interpreter version |
353 597
354 598 ###refimpl-mode modes
355 -most of [$cortav.lua]'s implementation-specific behavior is controlled by use of [!modes]. these are namespaced options which may have a boolean, string, or numeric value. boolean modes are set with the [$-y] [$-n] flags; other modes use the [$-m] flags.
599 +most of [`cortav.lua]'s implementation-specific behavior is controlled by use of [!modes]. these are namespaced options which may have a boolean, string, or numeric value. boolean modes are set with the [`-y] [`-n] flags; other modes use the [`-m] flags.
356 600
357 601 most modes are defined by the renderer backend. the following modes affect the behavior of the frontend:
358 602
359 603 + ID + type + effect
360 -| [$render:format]:| string | selects the [>refimpl-rend renderer] (default [$html])
361 -| [$parse:show-tree]:| flag | dumps the parse tree to the log after parsing completes
604 +| [`render:format]:| string | selects the [>refimpl-rend renderer] (default [`html])
605 +| [`parse:show-tree]:| flag | dumps the parse tree to the log after parsing completes
362 606
363 607 ##refimpl-rend renderers
364 -[$cortav.lua] implements a frontend-backend architecture, separating the parsing stage from the rendering stage. this means new renderers can be added to [$cortav.lua] relatively easily. currently, only an [>refimpl-rend-html HTML renderer] is included; however, a [$groff] backend is planned at some point in the future, so that PDFs and manpages can be generated from cortav files.
608 +[`cortav.lua] implements a frontend-backend architecture, separating the parsing stage from the rendering stage. this means new renderers can be added to [`cortav.lua] relatively easily. currently, only an [>refimpl-rend-html HTML renderer] is included; however, a [`groff] backend is planned at some point in the future, so that PDFs and manpages can be generated from cortav files.
365 609
366 610 ###refimpl-rend-html html
367 -the HTML renderer is activated with the incantation [$-m render:format html]. it is currently the default backend. it produces a single HTML file, optionally with CSS styling data, from a [$.ct] input file.
611 +the HTML renderer is activated with the incantation [`-m render:format html]. it is currently the default backend. it produces a single HTML file, optionally with CSS styling data, from a [`.ct] input file.
368 612
369 -it supports the following modes:
613 +####refimpl-rend-html-modes modes
614 +[`html] supports the following modes:
370 615
371 -* string (css length) [$html:width] sets a maximum width for the body content in order to make the page more readable on large displays
372 -* number [$html:accent] applies an accent hue to the generated webpage. the hue is specified in degrees, e.g. [$-m html:accent 0] applies a red accent.
373 -* flag [$html:dark-on-light] uses dark-on-light styling, instead of the default light-on-dark
374 -* flag [$html:fossil-uv] outputs an HTML snippet suitable for use with the Fossil VCS webserver. this is intended to be used with the unversioned content mechanism to host rendered versions of documentation written in cortav that's stored in a Fossil repository.
375 -* number [$html:hue-spread] generates a color palette based on the supplied accent hue. the larger the value, the more the other colors diverge from the accent hue.
376 -* string [$html:link-css] generates a document linking to the named stylesheet
377 -* flag [$html:gen-styles] embeds appropriate CSS styles in the document (default on)
378 -* flag [$html:snippet] produces a snippet of html instead of an entire web page. note that proper CSS scoping is not yet implemented (and can't be implemented hygienically since [$scoped] was removed 😢)
379 -* string [$html:title] specifies the webpage titlebar contents (normally autodetected from the document based on headings or directives)
616 +* string (css length) [`html:width] sets a maximum width for the body content in order to make the page more readable on large displays
617 +* number [`html:accent] applies an accent hue to the generated webpage. the hue is specified in degrees, e.g. [$-m html:accent 0] applies a red accent.
618 +* flag [`html:dark-on-light] uses dark-on-light styling, instead of the default light-on-dark
619 +* flag [`html:fossil-uv] outputs an HTML snippet suitable for use with the Fossil VCS webserver. this is intended to be used with the unversioned content mechanism to host rendered versions of documentation written in cortav that's stored in a Fossil repository.
620 +* number [`html:hue-spread] generates a color palette based on the supplied accent hue. the larger the value, the more the other colors diverge from the accent hue.
621 +* string [`html:link-css] generates a document linking to the named stylesheet
622 +* flag [`html:gen-styles] embeds appropriate CSS styles in the document (default on)
623 +* flag [`html:snippet] produces a snippet of html instead of an entire web page. note that proper CSS scoping is not yet implemented (and can't be implemented hygienically since [$scoped] was removed 😢)
624 +* string [`html:title] specifies the webpage titlebar contents (normally autodetected from the document based on headings or directives)
625 +* string [`html:font] specifies the default font to use when rendering as a CSS font specification (e.g. [`-m html:font 'Alegreya, Junicode, Georgia, "Times New Roman"])
380 626
381 627 ~~~
382 628 $ cortav readme.ct --out readme.html \
383 629 -m render:format html \
384 630 -m html:width 40em \
385 631 -m html:accent 80 \
386 632 -m html:hue-spread 35 \
387 633 -y html:dark-on-light # could also be written as:
388 634 $ cortav readme.ct -ommmmy readme.html render:format html html:width 40em html:accent 80 html:hue-spread 35 html:dark-on-light
389 635 ~~~
390 636
637 +#### directives
638 +[`html] supplies the following render directives.
639 +
640 +* [`%[*html] link [$rel] [$mime] [$href]]: inserts a [`<link>] tag in the header, for example, to link in an alternate stylesheet, or help feed readers find your atom or rss feed.
641 +** [`%[*html] link alternate\\ stylesheet text/css /res/style2.css]
642 +** [`%[*html] link alternate application/atom+xml /feed.atom]
643 +* [`%[*html] style [$id]]: adds the stylesheet referenced by [$id] into the document stylesheet. the stylesheet is specified using a [>rsrc resource].
644 +
645 +#### stylsheets
646 +the [`html] backend offers some additional directives for external CSS files that are embedded into the document, in order to simplify integration with the accent mechanism. these are:
647 +
648 +* [`@[*fg]]: resolves to a color expression denoting the selected foreground color. equivalent to [`[*tone](1)]
649 +* [`@[*bg]]: resolves to a color expression denoting the selected background color. equivalent to [`[*tone](0)]
650 +* [`@[*tone]\[/[$alpha]\]([$fac] \[[$shift] \[[$saturate]\]\] )]: resolves to a color expression. [$fac] is a floating-point value scaling from the background color to the foreground color. [$shift] is a value in degrees controlling how far the hue will shift relative to the accent. [$saturate] is a floating-point value controlling how satured the color is.
651 +
652 +###refimpl-rend-groff groff
653 +the [`groff] backend produces a text file suitable for supplying to a [`groff] compiler. [`groff] is the GNU implementation of a venerable typesetting system from the early days of UNIX
654 +
655 +as a convenience, the groff backend supports two modes of operation: it can write a [`groff] file directly to disk, or it can automatically launch a [`groff] process with the appropriate command line options and environment variables. this second mode is recommended unless you're rendering very large files to multiple formats, as [`groff] invocation is nontrivial and it's best to let the renderer handle that for you.
656 +
657 +####refimpl-rend-groff-modes modes
658 +[`groff] supports the following modes:
659 +
660 +* string [`groff:annotate] controls how footnotes will be handled.
661 +** [`footnote] places footnotes at the end of the page they are referenced on. if the same footnote is used on multiple pages, it will be duplicated on each.
662 +** [`secnote] places footnotes at the end of each section. footnotes used in multiple sections will be duplicated for each
663 +** [`endnote] places all footnotes at the end of the rendered document.
664 +* string [`groff:dev] names an output device (such as [`dvi] or[`pdf]). if this mode is present, [`groff] will be automatically invoked
665 +* string [`groff:title-page] takes an identifier that names a section. this section will be treated as the title page for the document.
666 +
667 +### directives
668 +* [`%[*pragma] title-page [$id]] sets the title page to section [$id]. this causes it to be specially formatted, with a large, centered title and subtitle.
669 +
670 +### quirks
671 +if the [`toc] extension is active but [`%[*toc]] directive is provided, the table of contents will be given its own section at the start of the document (after the title page, if any).
672 +
391 673 ## further directions
392 674
393 675 ### additional backends
394 676 it is eventually intended to support to following backends, if reasonably practicable.
395 677 * [*html]: emit HTML and CSS code to typeset the document. [!in progress]
396 678 * [*svg]: emit SVG, taking advantage of its precise layout features to produce a nicely formatted and paginated document. pagination can be accomplished through emitting multiple files or by assigning one layer to each page. [!long term]
397 679 * [*groff]: the most important output backend, rivalling [*html]. will allow the document to be typeset in a wide variety of formats, including PDF and manpage. [!short term]
398 680 * [*gemtext]: essentially a downrezzing of cortav to make it readable to Gemini clients
681 +* [*ast]: produces a human- and/or machine-readable dump of the document's syntax tree, to aid in debugging or for interoperation with systems that do not support `cortav` direcly. mode [`ast:repr] wil allow selecting formats for the dump. [`ast:rel] can be [`tree] (the default) to emit a hierarchical representation, or [`flat] to emit an array of nodes that convey hierarchy [^flatdoc by naming one another], rather than being placed inside one another. [`tree] is easier for humans to parse; [`flat] is easier for computers. origin information can be included for each node with the flag [`ast:debug-syms], but be aware this will greatly increase file size.
682 +** [`tabtree] [!(default)]: a hierarchical tree view, with the number of tabs preceding an item showing its depth in the tree
683 +** [`sexp]
684 +** [`binary]: emit a raw binary format that is easier for programs to read. maybe an lmdb or cdb file?
685 +** [`json]
686 +
687 + flatdoc: ~~~flat sexp example output [scheme]~~~
688 + (nodes
689 + (section (id . "section1")
690 + (anchor "introduction")
691 + (kind . "ordinary")
692 + (label . "section1-heading")
693 + (nodes
694 + "section1-heading"
695 + "para1"
696 + "para2"
697 + "hzrule"
698 + "para3"))
699 + (section (id . "section2")
700 + (kind . "ordinary")
701 + (label . "section2-heading")
702 + (nodes
703 + "para4"
704 + "hzrule"
705 + "para5"
706 + "list1"))
707 + (block list (id . "list1")
708 + (kind . "ordered")
709 + (nodes
710 + "para6"
711 + "list2"
712 + "para7"))
713 + (block list (id . "list2")
714 + (kind . "unordered")
715 + (nodes
716 + "para8"
717 + "para9"
718 + "para10"))
719 + (block para (id . "para1")
720 + (nodes "text1" "format1" "text3" "foonote1" "text4"))
721 + (block label (id . "section1-heading") (nodes "section1-heading-text"))
722 + (text (id . "section1-heading-text") "Contemplating the Anathema")
723 + (text (id . "text1")
724 + "Disquieting information has recently been disclosed to virtual journalists of the Giedi Prime infomatrix by sources close to the Hyperion Entity regarding the catatrophic Year of Schisms and the unidentified agents believed to be responsible for memetically engineering the near-collapse of the Church Galactic.")
725 + (span format (id . "format1")
726 + (style . "emph")
727 + (nodes . "text2"))
728 + (text (id . "text2") "Curiously,")
729 + (text (id . "text3") "his Cyber-Holiness")
730 + (text (id . "footnote1-caption-text") "Pope Chewbacca III")
731 + (span footnote (id . "footnote1")
732 + (note . "footnote1-text")
733 + (ref . "papal-disclaimer")
734 + (nodes
735 + "footnode1-caption-text"))
736 + (text (id . "text4") "has thus far had little to say on the matter, provoking rampant speculation among the faithful.")
737 + (footnote-def (id . "footnote1-def")
738 + (nodes "footnote1-text")
739 + (text (id . "footnote1-text") "Currently recognized as legitimate successor to Peter of Terra by 2,756 sects, rejected by 678 of mostly Neo-Lutheran origin, and decried as an antipope by 73, most notably Pope Peter II of Centaurus Secundus, leader of the ongoing relativistic crusade against star systems owned by Microsoft.")
740 + ;;; snip ;;;
741 + (document
742 + (nodes
743 + "section1" "section2")))
744 + ~~~
399 745
400 746 some formats may eventually warrant their own renderer, but are not a priority:
401 747 * [*text]: cortav source files are already plain text, but a certain amount of layout could be done using ascii art.
402 748 * [*ansi]: emit sequences of ANSI escape codes to lay out a document in a terminal-friendly way
403 749 * [*tex]: TeX is an unholy abomination and i neither like nor use it, but lots of people do and if cortav ever catches on, a TeX backend should probably be written eventually.
404 750
405 751 PDF is not on either list because it's a nightmarish mess of a format and groff, which is installed on most linux systems already, can easily generate PDFs
406 752
407 753 ### LCH support
408 754 right now, the use of color in the HTML renderer is very unsatisfactory. the accent mechanism operates on the basis of the CSS HSL function, which is not perceptually uniform; different hues will present different mixes of brightness and some (yellows?) may be ugly or unreadable.
409 755
410 756 the ideal solution would be to simply switch to using LCH based colors. unfortunately, only Safari actually supports the LCH color function right now, and it's unlikely (unless Lea Verou and her husband manage to work a miracle) that Colors Level 4 is going to be implemented very widely any time soon.
411 757
412 -this leaves us in an awkward position. we can of course do the math ourselves, working in LCH to implement the internal [$@tone] macro, and then "converting" these colors to HSL. unfortunately, you can't actually convert from LCH to HSL; it's like converting from pounds to kilograms. LCH can represent any color the human visual system can perceive; sRGB can't, and CSS HSL is implemented in sRGB. however, we could at least approximate something that would allow for perceptually uniform brightness, which would be an improvement, and this is probably the direction to go in, unless a miracle occurs and [$lch()] or [$color()] pop up in Blink.
758 +this leaves us in an awkward position. we can of course do the math ourselves, working in LCH to implement the internal [`@tone] macro, and then "converting" these colors to HSL. unfortunately, you can't actually convert from LCH to HSL; it's like converting from pounds to kilograms. LCH can represent any color the human visual system can perceive; sRGB can't, and CSS HSL is implemented in sRGB. however, we could at least approximate something that would allow for perceptually uniform brightness, which would be an improvement, and this is probably the direction to go in, unless a miracle occurs and [`lch()] or [`color()] pop up in Blink.
413 759
414 760 it may be possible to do a more reasonable job of handling colors in the postscript and TeX outputs. unsure about SVG but i assume it suffers the same problems HTML/CSS do. does groff even support color??
415 761
416 762 ### intent files
417 -there's currently no standard way to describe the intent and desired formatting of a document besides placing pragmas in the source file itself. this is extremely suboptimal, as when generating collections of documents, it's ideal to be able to keep all formatting information in one place. users should also be able to specify their own styling overrides that describe the way they prefer to read [$cortav] files, especially for uses like gemini or gopher integration.
763 +there's currently no standard way to describe the intent and desired formatting of a document besides placing pragmata in the source file itself. this is extremely suboptimal, as when generating collections of documents, it's ideal to be able to keep all formatting information in one place. users should also be able to specify their own styling overrides that describe the way they prefer to read [`cortav] files, especially for uses like gemini or gopher integration.
764 +
765 +at some point soon [`cortav] needs to address this by adding intent files that can be activated from outside the source file, such as with a command line flag or a configuration file setting. these will probably consist of lines that are interpreted as pragmata. in addition to the standard intent format however, individual implementations should feel free to provide their own ways to provide intent metadata; e.g. the reference implementation, which has a lua interpreter available, should be able to take a lua script that runs after the parse stage and generates . this will be particularly useful for the end-user who wishes to specify a particular format she likes reading her files in without forcing that format on everyone she sends the compiled document to, as it will be able to interrogate the document and make intelligent decisions about what pragmata to apply.
418 766
419 -at some point soon [$cortav] needs to address this by adding intent files that can be activated from outside the source file, such as with a command line flag or a configuration file setting. these will probably consist of lines that are interpreted as pragmata. in addition to the standard intent format however, individual implementations should feel free to provide their own ways to provide intent metadata; e.g. the reference implementation, which has a lua interpreter available, should be able to take a lua script that runs after the parse stage and generates . this will be particularly useful for the end-user who wishes to specify a particular format she likes reading her files in without forcing that format on everyone she sends the compiled document to, as it will be able to interrogate the document and make intelligent decisions about what pragmata to apply.
767 +intent files should also be able to define [>rsrc resources], [>ctxvar context variables], and macros.