| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
bonuses for breaking in particular places. (For example, it's
especially bad to break just after a heading, and especially good to
break just before one.)
[originally from svn r4064]
|
| |
|
|
|
|
| |
listing its absence as a bug :-)
[originally from svn r4063]
|
| |
|
|
| |
[originally from svn r4062]
|
| |
|
|
|
|
|
|
| |
font selection in headings, mentioning section numbers, bullets,
list item numbers, code paragraphs etc). The PS/PDF output now
actually looks like the document it's supposed to be :-)
[originally from svn r4061]
|
| |
|
|
|
|
|
| |
document, and references to external URLs for which acroread will
start a web browser.
[originally from svn r4060]
|
| |
|
|
|
|
|
| |
of semantics as to whether a `last' pointer pointed to the last
relevant thing in a list, or the one beyond that. Oops.
[originally from svn r4059]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an enormous amount of preprocessing and differ only in their final
output form, I've introduced a new type of layer called a
`pre-backend' (bk_paper.c is one). This takes all the information
passed to a normal backend and returns an arbitrary void *, which is
cached by the front end and passed on to any backend(s) which state
a desire for the output of that particular pre-backend. Thus, all
the page layout is done only once, and the PS and PDF backends
process the same data structures into two output files.
Note that these backends are _very_ unfinished; all sorts of vital
things such as section numbers, list markers, and title formatting
are missing, the paragraph justification doesn't quite work, and
advanced stuff like indexes and PDF interactive features haven't
even been started. But this basic framework generates valid output
files and is a good starting point, so I'm checking it in.
[originally from svn r4058]
|
| |
|
|
| |
[originally from svn r4056]
|
| |
|
|
| |
[originally from svn r4055]
|
| |
|
|
| |
[originally from svn r4054]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
items of the form `* stuff: Section 1.2.' are parsed by standalone
info as `Section 1.2' followed by a period, but are parsed by other
readers as `Section 1' followed by a period and then some spare
text. Therefore, I've changed strategy, and the index is now full of
*Note cross-references rather than menu items. On the plus side,
this means there are no longer any special characters which we can't
tolerate in an index entry; on the minus side, my shiny new
infrastructure for tracking the filepos of index entries is now
rendered pointless. I'll leave it in, though, since it may come in
handy again.
[originally from svn r4053]
|
| |
|
|
| |
[originally from svn r4052]
|
| |
|
|
|
|
|
|
|
|
| |
and index terms (the Info format doesn't like them). In the course
of this I've had to introduce some infrastructure for carrying a
filepos forward from the definition of every RHS index term so that
a particular backend can provide a usefully localised report of
which index term had a problem.
[originally from svn r4051]
|
| |
|
|
|
|
| |
to the test file. Ahem.
[originally from svn r4050]
|
| |
|
|
|
|
| |
appear to be used to automatically construct /usr/info/dir.
[originally from svn r4049]
|
| |
|
|
|
|
| |
directory before? Silly me.
[originally from svn r4048]
|
| |
|
|
|
|
|
| |
without going through the .texi source stage. A few things left to
do, notably documentation, but the basics all seem to be there.
[originally from svn r4047]
|
| |
|
|
| |
[originally from svn r4045]
|
| |
|
|
|
|
|
| |
the Unix PuTTY archive, to automatically generate version numbers
for Halibut release builds.
[originally from svn r4044]
|
| |
|
|
| |
[originally from svn r4043]
|
| |
|
|
| |
[originally from svn r4042]
|
| |
|
|
|
|
| |
manual. Added them.
[originally from svn r4038]
|
| |
|
|
| |
[originally from svn r4036]
|
| |
|
|
|
|
| |
Comments
[originally from svn r4035]
|
| |
|
|
|
|
| |
\quote{...}
[originally from svn r4034]
|
| |
|
|
|
|
| |
Comments
[originally from svn r4033]
|
| |
|
|
| |
[originally from svn r4032]
|
| |
|
|
|
|
|
|
|
| |
Special handling for \U so that it works. Tweak \title.
Make butTextArg transparent so that emphasis (e.g. in a header) shows
through.
Comment tweaks.
[originally from svn r4031]
|
| |
|
|
| |
[originally from svn r4030]
|
| |
|
|
|
|
| |
We do, so let's.
[originally from svn r4029]
|
| |
|
|
|
|
|
| |
consistently in the documentation than to confuse matters by saying
`back end'. One rogue back end removed.
[originally from svn r4028]
|
| |
|
|
| |
[originally from svn r4027]
|
| |
|
|
| |
[originally from svn r4026]
|
| |
|
|
| |
[originally from svn r4025]
|
| |
|
|
|
|
| |
I'd better document them...
[originally from svn r4024]
|
| |
|
|
| |
[originally from svn r4023]
|
| |
|
|
|
|
|
|
|
|
| |
parametric template, reuse the same mechanism to allow the <a
name="..."> markers on each section to be parametrised as well. That
way, any user who so desires can arrange for everything in a section
URL to be constructed from internal keywords, making it pretty
robust against section numbering changes.
[originally from svn r4019]
|
| |
|
|
|
|
|
|
|
| |
from its command-line option (`--text=foo.txt') and automatically
convert it into one or more notional \cfg directives. In the HTML
case this mechanism enables single-file mode as well as setting the
filename.
[originally from svn r4018]
|
| |
|
|
|
|
| |
name (or name schema, in HTML).
[originally from svn r4017]
|
| |
|
|
| |
[originally from svn r4016]
|
| |
|
|
| |
[originally from svn r4015]
|
| |
|
|
| |
[originally from svn r4014]
|
| |
|
|
|
|
| |
directives to be supplied on the Halibut command line.
[originally from svn r4013]
|
| |
|
|
|
|
|
| |
--html, --winhelp and --man (plus spelling variations :-), which
allow you to choose to run only a subset of backends.
[originally from svn r4012]
|
| |
|
|
| |
[originally from svn r4011]
|
| |
|
|
|
|
|
|
| |
rather than merely HTML, I thought it might be instructive to run it
through the W3C's XHTML validator. Consequent changes in this
checkin...
[originally from svn r4010]
|
| |
|
|
| |
[originally from svn r4007]
|
| |
|
|
|
|
|
|
|
| |
a single newline) immediately after their opening brace; this was
causing a normal paragraph to be started, thus making it fiddly and
annoying to arrange the first paragraph of a \lcont to be a code
para or anything else special. Now fixed.
[originally from svn r4005]
|
| |
|
|
| |
[originally from svn r4004]
|
| |
|
|
| |
[originally from svn r4003]
|