| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
the practice of using \dt and \dd in anything other than the obvious
interleaving.
[originally from svn r4417]
|
| |
|
|
|
|
| |
an integer charset ID.
[originally from svn r4317]
|
| |
|
|
| |
[originally from svn r4288]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(mknew/mknewa/resize) to the PuTTY ones (snew/snewn/sresize). snewn
and mknewa have their arguments opposite ways round; this may make
the change initially painful but in the long term will free me of a
nasty context switch every time I move between codebases. Also
sresize takes an explicit type operand which is used to cast the
return value from realloc, thus enforcing that it must be correct,
and arranging that if anyone tries to compile Halibut with a C++
compiler there should be a lot less pain.
[originally from svn r4276]
|
| |
|
|
| |
[originally from svn r4247]
|
| |
|
|
| |
[originally from svn r4112]
|
| |
|
|
|
|
|
|
|
|
|
| |
ustrfroma, utoa_dup and ufroma_dup now take a charset parameter, and
also have a variety of subtly distinct forms. Also, when a \cfg
directive is seen in the input file, the precise octet strings for
each parameter are kept in their original form as well as being
translated into Unicode, so that when they represent filenames they
can be used verbatim.
[originally from svn r4097]
|
| |
|
|
|
|
| |
representable in the output character set.
[originally from svn r4094]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
| |
the preamble: \copyright paragraphs are now treated identically to
normal paragraphs (so they appear precisely where they're put
instead of in a fixed location), _except_ that the Windows Help
backend also copies their text into the help file's copyright slot.
[originally from svn r4001]
|
| |
|
|
|
|
|
|
|
|
| |
any ordinary displayable paragraph(s) appearing before the first
chapter heading, meaning in particular that you can put lists, code
paragraphs etc in preambles. Of course, `\preamble' is still
supported for backwards compatibility, but it's now a zero-effect
paragraph marker.
[originally from svn r3981]
|
| |
|
|
| |
[originally from svn r3978]
|
| |
|
|
|
|
| |
there's nothing to go in it.
[originally from svn r3977]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
markup feature: a \c line in a code paragraph can now be followed by
an optional \e line indicating emphasised bits of its preceding \c.
This allows discretionary bolding and (italic/underline) emphasis
within code paragraphs, but without introducing an escape character
or breaking any existing input files. Users are warned that not all
backends are required to actually render these hints, and so they
should avoid depending on them 100% to convey semantic information
unless they know they're writing for a restricted range of backends.
[originally from svn r3965]
|
|
|
features commonly used in man pages: (a) the ability to nest
paragraph breaks, code paragraphs and other lists inside list items,
and (b) description lists as normally used in man pages to describe
command-line options.
[originally from svn r3954]
|
