| Commit message (Collapse) | Author |
|---|
|
end. There's a lot more _potentiality_ for new features than there
are actual new features just yet, but future highlights include:
configurable flavour of HTML (3.2, 4, XHTML Transitional or Strict),
proper character set support (this is half way there already), and
more flexible allocation of sections between multiple HTML files.
Meanwhile, immediate benefits include correct handling of special
characters within `author' and `description' strings, omission of
the filename part in hyperlinks within the same HTML file (in
particular, this means a single output file is now totally
independent of its filename), and hyperlinks to the index from the
top-level contents page (I'm amazed nobody has complained at the
lack of this yet!). There are no doubt some shiny new bugs as well,
but I'll never find them unless people start using the thing...
[originally from svn r4275]
|
|
printing preambles. Not quite sure how I missed that one!
[originally from svn r4201]
|
|
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]
|
|
that the GNOME help browser is perfectly happy with Halibut's HTML
_except_ that it doesn't approve of single quotes in places such as
<a href='here'>.
[originally from svn r4082]
|
|
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]
|
|
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]
|
|
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]
|
|
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 r4002]
|
|
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]
|
|
section title (which is not remotely unreasonable) got index
references added to them not only when the section title was
processed as part of its section, but also when it was processed as
part of contents navigation displays - in which situation it tended
to cause a link to, for example, the last section in the _previous_
file. Now we keep constant track of whether or not we're supposed to
be indexing things as we process text.
[originally from svn r3991]
|
|
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]
|
|
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]
|
|
complaints, it would probably help if I arranged that those things
had been _allocated_ in all cases, otherwise we merely exchange a
memory leak for a core dump. Duh.
[originally from svn r1916]
|
|
thingy, which seems moderately cool and has reported a few very
small memory leaks. Now apparently fixed.
[originally from svn r1863]
|
|
way as bk_text already does it (you can choose to have or not have
the "Section" at the start, and you can configure the suffix between
number and title).
[originally from svn r1839]
|
|
[originally from svn r1832]
|
|
which case the whole of the HTML output will be in a single file,
currently called Manual.html in the absence of configurability).
This includes the index, if present.
[originally from svn r1831]
|
|
[originally from svn r1800]
|
|
Windows is tricky otherwise, since Index.html clashes with
index.html. Bah).
[originally from svn r1575]
|
|
Contents entries are now, eg, "Chapter 1: Introduction" rather than just
"Introduction".
[originally from svn r1552]
|
|
near-complete functionality. All that's missing now is indexing and
horizontal rules.
[originally from svn r1449]
|
|
and _then_ setting x = x->next!).
[originally from svn r1445]
|
|
tree234 routines; they will be useful in the WinHelp stuff at least.
[originally from svn r1444]
|
|
versionids. I thought it might be nice to include only the
versionid(s) from the .but file(s) that gave rise to a particular
chapter file, but actually this is very badly defined (that
information is thrown away very early on in the front end) and in
any case thanks to cross-references every file _does_ depend on its
fellows. Better to put them all in throughout.
[originally from svn r1417]
|
|
implementation is inside out for part of it).
[originally from svn r1331]
|
|
[originally from svn r1328]
|
|
sorted out the HTML truncated-contents bug.
[originally from svn r1327]
|
|
[originally from svn r1159]
|
|
being incremented _past_ the NUL, so the rest of the string was lost.
[originally from svn r902]
|
|
without worry (oops)
[originally from svn r866]
|
|
* Frees up data structures
[originally from svn r835]
|
|
[originally from svn r834]
|
|
[originally from svn r833]
|
|
[originally from svn r828]
|
