463 lines
30 KiB
HTML
463 lines
30 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>Advanced Weaving with Patterns</title>
|
|
<link href="../docs-assets/Breadcrumbs.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<meta name="viewport" content="width=device-width initial-scale=1">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<meta http-equiv="Content-Language" content="en-gb">
|
|
|
|
<link href="../docs-assets/Base.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/Colours.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
<link href="../docs-assets/ConsoleText-Colours.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
|
|
</head>
|
|
<body>
|
|
<nav role="navigation">
|
|
<h1><a href="../index.html">
|
|
<img src="../docs-assets/Octagram.png" width=72 height=72">
|
|
</a></h1>
|
|
<ul><li><a href="index.html"><span class="selectedlink">inweb</span></a></li>
|
|
</ul><h2>Foundation Module</h2><ul>
|
|
<li><a href="../foundation-module/index.html">foundation</a></li>
|
|
<li><a href="../foundation-test/index.html">foundation-test</a></li>
|
|
</ul><h2>Example Webs</h2><ul>
|
|
<li><a href="../goldbach/index.html">goldbach</a></li>
|
|
<li><a href="../twinprimes/twinprimes.html">twinprimes</a></li>
|
|
<li><a href="../eastertide/index.html">eastertide</a></li>
|
|
</ul><h2>Repository</h2><ul>
|
|
<li><a href="https://github.com/ganelson/inweb"><img src="../docs-assets/github.png" height=18> github</a></li>
|
|
</ul><h2>Related Projects</h2><ul>
|
|
<li><a href="../../../inform/docs/index.html">inform</a></li>
|
|
<li><a href="../../../intest/docs/index.html">intest</a></li>
|
|
|
|
</ul>
|
|
</nav>
|
|
<main role="main">
|
|
<!--Weave of 'Advanced Weaving with Patterns' generated by Inweb-->
|
|
<ul class="crumbs"><li><a href="../index.html">Home</a></li><li><a href="index.html">inweb</a></li><li><a href="index.html#M">Manual</a></li><li><b>Advanced Weaving with Patterns</b></li></ul><p class="purpose">Customise your weave by creating a new pattern.</p>
|
|
|
|
<ul class="toc"><li><a href="M-awwp.html#SP1">§1. Patterns versus formats</a></li><li><a href="M-awwp.html#SP3">§3. Basic settings</a></li><li><a href="M-awwp.html#SP6">§6. Plugins</a></li><li><a href="M-awwp.html#SP9">§9. Embeddings</a></li><li><a href="M-awwp.html#SP10">§10. Syntax colouring</a></li><li><a href="M-awwp.html#SP12">§12. Templates</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. Patterns versus formats. </b>Every weave produces output in a "format". The formats are built in to Inweb,
|
|
and adding new ones would mean contributing code to the project: currently
|
|
we have HTML, ePub, Plain Text, PDF, DIV, and TeX.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">There is no way to specify the format at the command line. That's because
|
|
<span class="extract"><span class="extract-syntax">-weave-as P</span></span> tells Inweb to weave with a given "pattern": a weave pattern
|
|
combines a choice of format with other settings to produce a customised
|
|
weave. Patterns can also be based on other patterns: one can, in effect, say
|
|
"I want something like P but with some differences". For example, the Inweb
|
|
manual at GitHub is woven with <span class="extract"><span class="extract-syntax">-weave-as GitHubPages</span></span>, which is a pattern
|
|
based heavily on a generic website-producing pattern called <span class="extract"><span class="extract-syntax">HTML</span></span>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The upshot of all this is that if you want a website, but one which looks and
|
|
behaves differently from what <span class="extract"><span class="extract-syntax">-weave-as HTML</span></span> would give, you should create
|
|
a new pattern based on it, and work from there. But patterns are not just
|
|
for websites.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. </b>A pattern definition is a directory containing various files, which we'll
|
|
get to in due course. Inweb looks for patterns in three places in turn:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) The location given by the <span class="extract"><span class="extract-syntax">patterns</span></span> command in the current colony file,
|
|
if there is one: see <a href="M-mwiw.html" class="internal">Making Weaves into Websites</a>.
|
|
</li><li>(b) The <span class="extract"><span class="extract-syntax">Patterns</span></span> subdirectory of the current web, if there is a current web,
|
|
and if it has such a subdirectory.
|
|
</li><li>(c) The set of built-in patterns supplied with Inweb, at <span class="extract"><span class="extract-syntax">inweb/Patterns</span></span>
|
|
in the usual distribution.
|
|
</li></ul>
|
|
<p class="inwebparagraph">For example, the command
|
|
</p>
|
|
|
|
<pre class="ConsoleText-displayed-code all-displayed-code">
|
|
<span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-element-syntax">$</span><span class="ConsoleText-plain-syntax"> </span><span class="ConsoleText-function-syntax">inweb/Tangled/inweb</span><span class="ConsoleText-plain-syntax"> inweb/Examples/goldbach</span><span class="ConsoleText-identifier-syntax"> -weave-as</span><span class="ConsoleText-plain-syntax"> Tapestry</span>
|
|
</pre>
|
|
<p class="inwebparagraph">didn't set a colony file, so (a) doesn't apply. Inweb first tries
|
|
<span class="extract"><span class="ConsoleText-extract-syntax">inweb/Examples/goldbach/Patterns/Tapestry</span></span> and then <span class="extract"><span class="ConsoleText-extract-syntax">inweb/Patterns/Tapestry</span></span>.
|
|
If it can't find either, Inweb issues an error.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. Basic settings. </b>Patterns allow for extensive customisation of the woven output, especially
|
|
through the use of plugins (see below). But they can also be extremely minimal.
|
|
The one absolute requirement is to include a configuration file called
|
|
<span class="extract"><span class="ConsoleText-extract-syntax">pattern.txt</span></span>, which consists of a series of simple one-line commands.
|
|
In this file, blank lines, leading and trailing white space are all ignored,
|
|
as is any file whose first character is <span class="extract"><span class="ConsoleText-extract-syntax">#</span></span>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The first genuine line of the file should always give the pattern's name,
|
|
and say what if anything it is based on. For example, this might be:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> name: Tapestry based on HTML</span>
|
|
</pre>
|
|
<p class="inwebparagraph">That is the only compulsory content; with that one line in one file, the
|
|
Tapestry pattern is ready for use. (But of course it behaves identically
|
|
to HTML in every respect, so it's not very useful yet.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Do not get these into loops, with A based on B and B based on A.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">For a pattern not based on an existing one, simply omit the "based on X"
|
|
part. Thus, for example,
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> name: HTML</span>
|
|
</pre><p class="inwebparagraph"><a id="SP4"></a><b>§4. </b>There are then a handful of other, optional, settings. The following are
|
|
all inherited automatically from the pattern we are based on, unless we
|
|
set them ourselves.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> format: F</span>
|
|
</pre>
|
|
<p class="inwebparagraph">sets the format. At present, this must be <span class="extract"><span class="extract-syntax">HTML</span></span>, <span class="extract"><span class="extract-syntax">plain</span></span> (plain text),
|
|
<span class="extract"><span class="extract-syntax">ePub</span></span>, <span class="extract"><span class="extract-syntax">TeX</span></span>, <span class="extract"><span class="extract-syntax">DVI</span></span>, or <span class="extract"><span class="extract-syntax">PDF</span></span>.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> number sections: yes</span>
|
|
<span class="plain-syntax"> number sections: no</span>
|
|
</pre>
|
|
<p class="inwebparagraph">causes the weaver to apply numbers to section headings: the first included will
|
|
be number 1, and so on. Default is <span class="extract"><span class="extract-syntax">no</span></span>.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> embed CSS: yes</span>
|
|
<span class="plain-syntax"> embed CSS: no</span>
|
|
</pre>
|
|
<p class="inwebparagraph">causes the weaver to embed copies of CSS files into each HTML file it creates,
|
|
rather than to link to them. Default is <span class="extract"><span class="extract-syntax">no</span></span>, and there's no effect on non-HTML
|
|
formats.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> default range: R</span>
|
|
</pre>
|
|
<p class="inwebparagraph">tells the weaver to assume the range <span class="extract"><span class="extract-syntax">R</span></span>, if the user tries to weave a
|
|
multi-section web with this pattern. (For example, the standard HTML pattern
|
|
sets this to <span class="extract"><span class="extract-syntax">sections</span></span>, causing a swarm of individual HTML files to be produced.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Lastly, there are commands to do with plugins, covered below, which are also
|
|
inherited.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. </b>And there are a few settings which are not inherited: they apply only to the
|
|
pattern being defined, not to other patterns based on it.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> tex command: C</span>
|
|
</pre>
|
|
<p class="inwebparagraph">tells the weaver that the TeX typesetting system should be invoked with the
|
|
shell command <span class="extract"><span class="extract-syntax">C</span></span>. Default is <span class="extract"><span class="extract-syntax">tex</span></span>. Similarly for <span class="extract"><span class="extract-syntax">pdftex command: C</span></span>, used
|
|
when we want to make a PDF rather than a DVI.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> open command: C</span>
|
|
</pre>
|
|
<p class="inwebparagraph">tells the weaver to use the shell command <span class="extract"><span class="extract-syntax">C</span></span> if it wants to open the woven
|
|
file (i.e., on the user's computer) after it finishes. Default is <span class="extract"><span class="extract-syntax">open</span></span>,
|
|
which works nicely for MacOS.
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> bibliographic data: K = V</span>
|
|
</pre>
|
|
<p class="inwebparagraph">tells the weaver to override the bibliographic data on any web it weaves, setting
|
|
the key <span class="extract"><span class="extract-syntax">K</span></span> to the value <span class="extract"><span class="extract-syntax">V</span></span>. For example:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> bibliographic data: Booklet Title = A formal grammar for Inform 7</span>
|
|
</pre><p class="inwebparagraph"><a id="SP6"></a><b>§6. Plugins. </b>Plugins are named bundles of resources which are sometimes added to a weave,
|
|
and sometimes not, depending on its needs; they are placed in the pattern's
|
|
folder, and Inweb has access to the plugins not only for the current pattern,
|
|
but also for any pattern(s) it is based on. Plugins were designed for HTML,
|
|
but there's no reason they shouldn't also be useful for other formats.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">A plugin is identified by name alone, case-insensitively, and that name should
|
|
be a single alphanumeric word. For example, the HTML pattern file says
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> plugin: Base</span>
|
|
</pre>
|
|
<p class="inwebparagraph">and this ensures that every file woven by this pattern, or any pattern based
|
|
on it, will use <span class="extract"><span class="extract-syntax">Base</span></span>. There can be multiple such commands, for multiple such
|
|
plugins, and the ability isn't restricted to HTML alone.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">In addition, the HTML format:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) includes <span class="extract"><span class="extract-syntax">MathJax3</span></span> if the woven file needs mathematics notation;
|
|
</li><li>(b) includes <span class="extract"><span class="extract-syntax">Breadcrumbs</span></span> if it has a breadcrumb navigation trail;
|
|
</li><li>(c) includes <span class="extract"><span class="extract-syntax">Carousel</span></span> if it has any image carousels;
|
|
</li><li>(d) includes <span class="extract"><span class="extract-syntax">Popups</span></span> if it has any clickable popups (for example, to show
|
|
function usage);
|
|
</li><li>(e) includes <span class="extract"><span class="extract-syntax">Bigfoot</span></span> if it includes footnotes.
|
|
</li></ul>
|
|
<p class="inwebparagraph">Two of these draw on other open-source projects:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) <span class="extract"><span class="extract-syntax">MathJax3</span></span> is an excellent rendering system for mathematics on the web: see
|
|
<a href="https://docs.mathjax.org/en/latest/index.html" class="external">https://docs.mathjax.org/en/latest/index.html</a>
|
|
</li><li>(b) <span class="extract"><span class="extract-syntax">Bigfoot</span></span> is adapted from a popularly used piece of web coding: see
|
|
<a href="https://github.com/lemonmade/bigfoot" class="external">https://github.com/lemonmade/bigfoot</a>
|
|
</li></ul>
|
|
<p class="inwebparagraph">But if you would like your pattern to use different plugins to handle
|
|
mathematics and footnoting, provide lines like these in your pattern file,
|
|
but with your preferred plugin names:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> mathematics plugin: MathJax3</span>
|
|
<span class="plain-syntax"> footnotes plugin: Bigfoot</span>
|
|
</pre>
|
|
<p class="inwebparagraph"><span class="extract"><span class="extract-syntax">Bigfoot</span></span> may eventually need to be simplified and rewritten: its big feet
|
|
presently tread on the <span class="extract"><span class="extract-syntax">MathJax3</span></span> plugin, so right now it's not possible to
|
|
have mathematics in a footnote when <span class="extract"><span class="extract-syntax">Bigfoot</span></span> is in use.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP7"></a><b>§7. </b>It's also possible to supply your own version of any plugin you would like
|
|
to tinker with. If you want <span class="extract"><span class="extract-syntax">Carousel</span></span> to have rather different CSS effects,
|
|
for example, make your own copy of <span class="extract"><span class="extract-syntax">Carousel</span></span> (copying it from the one in
|
|
the Inweb distribution at <span class="extract"><span class="extract-syntax">inweb/Patterns/HTML/Carousel</span></span>) and place it in your
|
|
own pattern. Your version will prevail over the built-in one.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP8"></a><b>§8. </b>So what's in a plugin? There's not much to it. Every file in a plugin, whose
|
|
name does not begin with a <span class="extract"><span class="extract-syntax">.</span></span>, is copied into the weave: that means it either
|
|
gets copied to the weave destination directory, or possibly to the <span class="extract"><span class="extract-syntax">assets</span></span>
|
|
directory specified in the colony file (if there is one). However:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) If the format is HTML, and the filename ends <span class="extract"><span class="extract-syntax">.css</span></span>, then a link to the
|
|
CSS file is automatically included in the head of the file. If the pattern
|
|
says to <span class="extract"><span class="extract-syntax">embed CSS</span></span> (see above), then the file is spliced in rather than
|
|
being copied.
|
|
</li><li>(b) If the format is HTML, and the filename ends <span class="extract"><span class="extract-syntax">.js</span></span>, then a link to the
|
|
Javascript file is automatically included in the head of the file.
|
|
</li></ul>
|
|
<p class="inwebparagraph">For example, the <span class="extract"><span class="extract-syntax">Breadcrumbs</span></span> plugin contains an image file and a CSS file;
|
|
both are copied across, but a link to the CSS file is also included in the
|
|
woven file needing to use the plugin.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP9"></a><b>§9. Embeddings. </b>Patterns with the HTML format may also want to provide "embeddings". These
|
|
are for embedded video/audio or other gadgets, and each different "service" —
|
|
<span class="extract"><span class="extract-syntax">YouTube</span></span>, <span class="extract"><span class="extract-syntax">SoundCloud</span></span>, and such — is represented by an embedding file.
|
|
Inweb looks for these in the pattern's <span class="extract"><span class="extract-syntax">Embedding</span></span> subdirectory, if there is
|
|
one; then it tries in the pattern we are based on, and so on until it gives
|
|
up and throws an error.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The services in the standard Inweb installation, then, are in
|
|
<span class="extract"><span class="extract-syntax">inweb/Patterns/HTML/Embeddings</span></span>. It's easy to add new ones; for example,
|
|
by creating a similar fragment in <span class="extract"><span class="extract-syntax">Tapestry/Embedding/WebTubeo.html</span></span> you
|
|
would provide for embedding videos from <span class="extract"><span class="extract-syntax">WebTubeo</span></span> when using your pattern.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP10"></a><b>§10. Syntax colouring. </b>No two people ever agree on the ideal colour scheme for syntax-colouring,
|
|
so one prime reason to create a custom pattern is to change Inweb's defaults.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Suppose Inweb wants to weave an extract of code written in, say, C. It will
|
|
use the programming language definition for C to make a syntax-colouring,
|
|
but then use the weave pattern to decide the colour scheme. For example,
|
|
it's up to the C language to say which text is a function name: but it's up
|
|
to the pattern to say whether functions are red or green.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">A pattern based on HTML may provide a subdirectory called <span class="extract"><span class="extract-syntax">Colouring</span></span>. If it
|
|
does, then the contents will be CSS files which provide colour schemes for
|
|
different programming languages. The scheme <span class="extract"><span class="extract-syntax">Colours.css</span></span> is the fallback,
|
|
and is used for any language not providing a colour scheme; otherwise, a
|
|
language called, say, <span class="extract"><span class="extract-syntax">Anaconda</span></span> would be coloured by <span class="extract"><span class="extract-syntax">Anaconda-Colours.css</span></span>.
|
|
Inweb looks first in the <span class="extract"><span class="extract-syntax">Colouring</span></span> directory of the current pattern, then
|
|
tries the pattern it is based on, and so on.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The practical effect is that if you want a pattern to colour Anaconda programs
|
|
in your own preferred way — let's call this hypothetical pattern <span class="extract"><span class="extract-syntax">SnakeSkin</span></span> —
|
|
then you need only write two files: <span class="extract"><span class="extract-syntax">SnakeSkin/pattern.txt</span></span>, consisting of
|
|
the single line
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> name: SnakeSkin based on HTML</span>
|
|
</pre>
|
|
<p class="inwebparagraph">(or perhaps based on <span class="extract"><span class="extract-syntax">GitHubPages</span></span>, if you want to host there); and then
|
|
a colouring file in <span class="extract"><span class="extract-syntax">SnakeSkin/Colouring/Anaconda-Colours.css</span></span>. You should
|
|
make this by copying the default <span class="extract"><span class="extract-syntax">Colours.css</span></span> and tinkering.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP11"></a><b>§11. </b>Note that Inweb supports multiple languages in the same weave, each having
|
|
their own colour schemes. To do this, it renames CSS spans on the fly in
|
|
order to prevent namespace clashes. But you can forget this, because it's
|
|
automatic.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP12"></a><b>§12. Templates. </b>The final possible ingredient for a pattern is a "template"; this is a file
|
|
like a pro-forma letter, into which just the details need to be entered.
|
|
Inweb does this in two main circumstances:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) For each woven file, for example each HTML page generated in a website,
|
|
Inweb looks for <span class="extract"><span class="extract-syntax">template-body.html</span></span> (or <span class="extract"><span class="extract-syntax">.tex</span></span>, or <span class="extract"><span class="extract-syntax">.txt</span></span> — whatever
|
|
file extension is used for files in the current format), and uses that
|
|
to top and tail the weaver's output. Not all formats or patterns need that.
|
|
</li><li>(b) If Inweb is weaving a large number of individual files for sections or
|
|
chapters, it will try also to make an accompanying contents page, though
|
|
it uses the term "index" for this. It does this by looking for the
|
|
template <span class="extract"><span class="extract-syntax">template-index.html</span></span> — this time, it's always HTML: the idea is
|
|
that whatever file type you're making, you will want an HTML index page
|
|
offering downloads or links to them.
|
|
</li></ul>
|
|
<p class="inwebparagraph">In fact the same process, called "collation", is also used internally to
|
|
produce navigation sidebars in HTML, and to inject HTML into headers for
|
|
the sake of plugins. But the author of a pattern can't control that, whereas
|
|
she can write her own <span class="extract"><span class="extract-syntax">template-body.html</span></span> and/or <span class="extract"><span class="extract-syntax">template-index.html</span></span>.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP13"></a><b>§13. </b>For example, here is a template file for making an HTML page:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"></span>
|
|
<span class="plain-syntax"><html></span>
|
|
<span class="plain-syntax"> <head></span>
|
|
<span class="plain-syntax"> <title></span><span class="function-syntax">[[Booklet Title]]</span><span class="plain-syntax"></title></span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Plugins]]</span>
|
|
<span class="plain-syntax"> </head></span>
|
|
<span class="plain-syntax"> <body></span>
|
|
<span class="function-syntax">[[Weave Content]]</span>
|
|
<span class="plain-syntax"> </body></span>
|
|
<span class="plain-syntax"></html></span>
|
|
</pre>
|
|
<p class="inwebparagraph">The weaver uses this to generate any HTML page of program taken from the
|
|
web being woven. What you see is what you get, except for the placeholders in
|
|
double square brackets:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) <span class="extract"><span class="extract-syntax">[[Weave Content]]</span></span> expands to the body of the web page — the headings,
|
|
paragraphs and so on.
|
|
</li><li>(b) <span class="extract"><span class="extract-syntax">[[Plugins]]</span></span> expands to any links to CSS or Javascript files needed
|
|
by the plugins being used — see above.
|
|
</li><li>(c) Any bibliographic datum for the web expands to its value: thus <span class="extract"><span class="extract-syntax">[[Title]]</span></span>,
|
|
<span class="extract"><span class="extract-syntax">[[Author]]</span></span> and so on. Booklet Title is one of these, but the weaver always
|
|
sets it to a sensible title for the current file being woven — typically the
|
|
name of a section or chapter, if that's what the file will contain. Another
|
|
sometimes useful case to know is <span class="extract"><span class="extract-syntax">[[Capitalized Title]]</span></span>, which is the title
|
|
in BLOCK CAPITAL LETTERS.
|
|
</p>
|
|
|
|
</li></ul>
|
|
<p class="inwebparagraph"><a id="SP14"></a><b>§14. </b>Other placeholders, not used in the example above, include:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) <span class="extract"><span class="extract-syntax">[[Template X]]</span></span> expands to an insertion of the template file <span class="extract"><span class="extract-syntax">X</span></span>.
|
|
</li><li>(b) <span class="extract"><span class="extract-syntax">[[Navigation]]</span></span> expands to the navigation sidebar in use when weaving
|
|
a colony of webs — see <a href="M-mwiw.html" class="internal">Making Weaves into Websites</a> for more, and for
|
|
syntaxes to do with links and URLs.
|
|
</li><li>(c) <span class="extract"><span class="extract-syntax">[[Breadcrumbs]]</span></span> expands to the HTML for the breadcrumb trail.
|
|
</p>
|
|
|
|
</li></ul>
|
|
<p class="inwebparagraph"><a id="SP15"></a><b>§15. </b>The <span class="extract"><span class="extract-syntax">template-index.html</span></span> file has access to additional placeholders
|
|
enabling it to generate contents pages:
|
|
</p>
|
|
|
|
<ul class="items"><li>(a) One of the following details about the entire-web PDF (see below):
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Complete Leafname]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Complete Extent]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Complete PDF Size]]</span>
|
|
</pre>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
</li></ul>
|
|
<ul class="items"><li>(b) One of the following details about the "current chapter" (again, see below):
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Chapter Title]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Chapter Purpose]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Chapter Leafname]]</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Chapter Extent]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Chapter PDF Size]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Chapter Errors]]</span>
|
|
</pre>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
</li></ul>
|
|
<ul class="items"><li> The leafname is that of the typeset PDF; the extent is a page count;
|
|
the errors result is a usually blank report.
|
|
</li><li>(c) One of the following details about the "current section" (again, see below):
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Section Title]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Section Purpose]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Section Leafname]]</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Section Extent]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Section PDF Size]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Section Errors]]</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Section Lines]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Section Paragraphs]]</span><span class="plain-syntax"> </span><span class="function-syntax">[[Section Mean]]</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Section Source]]</span>
|
|
</pre>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
</li></ul>
|
|
<ul class="items"><li> Lines and Paragraphs are counts of the number of each; the Source
|
|
substitution is the leafname of the original <span class="extract"><span class="extract-syntax">.w</span></span> file. The Mean is the
|
|
average number of lines per paragraph: where this is large, the section
|
|
is rather raw and literate programming is not being used to the full.
|
|
</p>
|
|
|
|
</li></ul>
|
|
<p class="inwebparagraph"><a id="SP16"></a><b>§16. </b><span class="extract"><span class="extract-syntax">[[Repeat Chapter]]</span></span> and <span class="extract"><span class="extract-syntax">[[Repeat Section]]</span></span> begin blocks of lines which
|
|
are repeated for each chapter or section: the material to be repeated
|
|
continues to the matching <span class="extract"><span class="extract-syntax">[[End Repeat]</span></span> line. The ``current chapter or
|
|
section'' mentioned above is the one selected in the current innermost
|
|
loop of that description.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><span class="extract"><span class="extract-syntax">[[Select ...]]</span></span> and <span class="extract"><span class="extract-syntax">[[End Select]</span></span> form a block which behaves like
|
|
a repetition, but happens just once, for the named chapter or section.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">For example, the following pattern:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> To take chapter 3 as an example, for instance, we find -</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Select 3]]</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[Repeat Section]]</span>
|
|
<span class="plain-syntax"> Section </span><span class="function-syntax">[[Section Title]]</span><span class="plain-syntax">, </span><span class="function-syntax">[[Section Code]]</span><span class="plain-syntax">, </span><span class="function-syntax">[[Section Lines]]</span><span class="plain-syntax"> lines.</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[End Repeat]]</span>
|
|
<span class="plain-syntax"> </span><span class="function-syntax">[[End Select]]</span>
|
|
</pre>
|
|
<p class="inwebparagraph">weaves a report somewhat like this:
|
|
</p>
|
|
|
|
<pre class="displayed-code all-displayed-code">
|
|
<span class="plain-syntax"> To take chapter 3 as an example, for instance, we find -</span>
|
|
<span class="plain-syntax"> Section Lexer, 3/lex, 1011 lines.</span>
|
|
<span class="plain-syntax"> Section Read Source Text, 3/read, 394 lines.</span>
|
|
<span class="plain-syntax"> Section Lexical Writing Back, 3/lwb, 376 lines.</span>
|
|
<span class="plain-syntax"> Section Lexical Services, 3/lexs, 606 lines.</span>
|
|
<span class="plain-syntax"> Section Vocabulary, 3/vocab, 338 lines.</span>
|
|
<span class="plain-syntax"> Section Built-In Words, 3/words, 1207 lines.</span>
|
|
</pre><hr class="tocbar">
|
|
<ul class="toc"><li><a href="M-mwiw.html">Back to 'Making Weaves into Websites'</a></li><li><a href="M-spl.html">Continue with 'Supporting Programming Languages'</a></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
|
|
</main>
|
|
</body>
|
|
</html>
|
|
|