Halibut: yet another free document preparation system

Halibut is a documentation production system, with elements similar to TeX, debiandoc-sgml, TeXinfo, and others. It is primarily targeted at people producing software manuals.

What does it do?

Halibut reads documentation source in a single input format, and produces multiple output formats containing the same text. The supported output formats are:

• Plain ASCII text
• HTML
• PDF
• PostScript
• Unix man pages
• Unix info, generated directly as .info files rather than .texi sources
• Windows HTML Help (.CHM files), generated directly without needing a separate help compiler.
• Windows WinHelp (old-style .HLP files), also generated directly.

Other notable features include:

• Hypertext cross-references are ubiquitous where possible. In particular, the HTML and PDF output both have hyperlinks in every reference between sections, and throughout the index and contents sections. (It seems daft to me that so many PDF documents fail to have this; it's one of the most useful features of PDF.)
• Support for international characters via Unicode, with the ability to fall back to an alternative representation. For example, you can write \u00F6{oe}, and in output formats that support it you will see ‘ö’ whereas in those that don't you will see ‘oe’.
• Comprehensive indexing support. Indexing is easy in the simple case: as you write the manual, you just wrap a word or two in \i{this wrapper}, and those words will appear in the index. More complex indexing is also supported, such as
  • adding references to things you never explicitly said
  • rewriting the appearance of index entries for a consistent style
  • duplicating index entries to several places because you don't know which concept they'll be looked up under
  • merging references to several things into one combined list.
• Portability. The Halibut source code is portable ANSI C (apart from a dependency on having at least a 32-bit platform), so it should run without change on Unix, Windows, BeOS, MacOS, VMS, or whatever other (non-16-bit) OS you fancy. (Well, you might have trouble outputting PDF under VMS, due to file typing issues. I dunno.)
• Configurability. Each output format supplies configuration directives, so it is easy to tailor the HTML output (say) to contain a standard header with links to other parts of a site, or to use a style sheet, or whatever.

So why didn't you just use…

A common question is why I had to write a new documentation system rather than using an existing one.

TeX is fundamentally geared towards typesetting on to a printed page, so it didn't seem feasible to get it to output any of the more markup-oriented formats such as man pages and Windows Help.

TeXinfo can generate both printed manuals and on-line help, but neither one is very pretty IMO; and the on-line help output is limited to info format, which I didn't fancy post-processing into Windows Help, HTML etc.

debiandoc-sgml generates a good range of file formats, suggesting that it would probably not have been too hard to hack in a couple more; but when I looked at it I didn't see indexing support at anything like the level I wanted. Indexing is a big and tricky task, and I would hate to hack index support into a document producer after it was written; better to design it in from scratch.

DocBook wasn't well known enough for me to have heard of it when this project started. When it was later brought to my attention, I looked at the DocBook input format and simply didn't like it. For a start, it just involved too much typing for my taste: all the keywords are far too long (<appendix> rather than \A, for example), and the SGML/XML syntax requires you to type each keyword again when you close the section. I just prefer the TeX-like backslash-and-braces markup syntax to the HTMLish angle-brackets-and-slashes one. I was also suspicious of DocBook's very detailed semantic markup such as individually annotating things like people's names; I find writing manuals hard enough work as it is, without having to write as much metadata as text. Perhaps, if anyone asks for it, I might consider writing a DocBook output format for Halibut, so that Halibut input can be conveniently translated into DocBook format.

Where did this crazy idea come from?

This crazy idea came to me while I was working on NASM, and wanted the documentation to be available on the project's web site as well as in printable and online-viewable formats. I hacked together a Perl implementation of most of the Halibut concepts, without any real design, and it worked well enough to get the NASM manual off the ground.

However, the Perl version (which is still distributed in the current NASM archive as far as I know) had serious limitations, most noticeably that it was extremely slow. Also the code was very hard to maintain (largely because I wrote a lot of the parser as line-noise regexps), the index management had some good ideas but implemented them in fundamentally broken ways … It just didn't seem sensible to continue trying to put features into it. So I rewrote it from the ground up in portable C, learning from all my mistakes in the original Perl version (‘build one to throw away’).

Why on earth ‘Halibut’? What relevance does the name have to anything?

Historical reasons. It's probably better not to ask.

What is its current status?

Halibut 1.3 was released on 2021-10-30, and supports all of the features described above.

You can download the release source code here [halibut-1.3.tar.gz], or you can read the release documentation online in HTML, PDF or plain text.

If you're using Windows, you can also download a Windows executable, and the same documentation again in the form of a Windows HTML Help file.

Alternatively, if you want to keep up to date with the very latest development, you can check the development sources out from our git repository. This uses git submodule, so in order to check out everything you need, you'll need the --recursive option:

git clone --recursive https://git.tartarus.org/simon/halibut.git

Alternatively, you can browse the repository on the web, here.