I became aware a few months ago that enough is known about CHM files
that free software _can_ write them without benefit of the MS HTML
Help compiler - in particular there's a thing called 'chmcmd' in the
Free Pascal Compiler software distribution which is more or less a
drop-in replacement for hhc.exe itself.

But although depending on chmcmd would be a bit nicer than depending
on hhc.exe, Halibut has always preferred to do the whole job itself if
it can. So here's my own from-scratch code to generate CHM directly
from Halibut source.

The new output mode is presented as a completely separate top-level
thing independent of HTML mode. Of course, in reality, the two back
ends share all of the HTML-generation code, differing only in a few
configuration defaults and the minor detail of what will be _done_
with each chunk of HTML as it's generated (this is what the recent
refactoring in b3db1cce3 was in aid of). But even so, the output modes
are properly independent from a user-visible-behaviour perspective:
they use parallel sets of config directives rather than sharing the
same ones (you can set \cfg{html-foo} and \cfg{chm-foo} independently,
for a great many values of 'foo'), and you can run either or neither
or both as you choose in a given run of Halibut.

The old HTML Help support, in the form of some config directives for
HTML mode to output the auxiliary files needed by hhc.exe, is still
around and should still work the same as it always did. I have no real
intention of removing it, partly for the reasons stated in the manual
(someone might find it useful to have Halibut generate the .HHP file
once and then make manual adjustments to it, so that they can change
styling options that the direct CHM output doesn't permit), and mostly
because it wouldn't save a great deal of code or complexity in any
case - the big two of the three auxiliary files (the HHC and HHK) have
to be generated _anyway_ to go inside the .CHM, so all the code would
have to stay around regardless.

I'm not quite sure why I ever thought it was a good idea to have a
central variadic error() function taking an integer error code
followed by some list of arguments that depend on that code. It now
seems obvious to me that it's a much more sensible idea to have a
separate function per error, so that we can check at compile time that
the arguments to each error call are of the right number and type! So
I've done that instead.

A side effect is that the errors are no longer formatted into a
fixed-size buffer before going to stderr, so I can remove all the
%.200s precautions in the format strings.

[originally from svn r9639]

the special filename '-'.

[originally from svn r8728]

fonts is difficult.

[originally from svn r7281]

[originally from svn r6653]

by the use of a comma as a decimal separator.

[originally from svn r6456]

character sets.

(Also make libcharset `return_in_enum' values saner.)

[originally from svn r5341]
[this svn revision also touched charset,filter,timber]

 - After discussion with Simon, change the default input charset back to ASCII,
   rather than trying to work it out from the locale, for the sake of promoting
   .but file portability.

 - Add a new command-line option "--input-charset=csname", which overrides the
   ASCII default for all input files (since there's no other way to use a
   non-ASCII-compatible input file).

 - Output a warning if -Cinput-charset:foo is specified that it has no effect.

 - Update the docs to match all this. Also try to clarify some other things in
   this area that caught me out.

[originally from svn r5332]

(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]

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]