summaryrefslogtreecommitdiff
path: root/doc/manpage.but (follow)
Commit message (Collapse)AuthorAge
* New output mode to write CHM files directly.Simon Tatham2017-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Switch chiark URLs to https.Simon Tatham2017-05-07
|
* Remove Subversion expanded keywords everywhere.Simon Tatham2014-09-24
| | | | | | | | | | The \versionids in the docs are now added by the bob script; the one in inputs/test.but has been replaced by fixed text (it didn't matter what it contained anyway, of course, for test purposes), and the one in misc/halibut.vim has simply been removed (it wasn't actually expanded by svn anyway - it still had its old CVS value). [originally from svn r10253]
* Add a --list-fonts option, since getting PostScript names out of TrueTypeBen Harris2007-02-13
| | | | | | fonts is difficult. [originally from svn r7281]
* Actually, the separator in the "NAME" section really ought to be anBen Harris2006-12-11
| | | | | | EN DASH, falling back to MINUS and then HYPHEN-MINUS. Make it so. [originally from svn r6992]
* Fix amusing cut-and-paste error in section keywords :-)Simon Tatham2006-12-11
| | | | [originally from svn r6989]
* Mention PDF before PostScript everywhere, partly because PDF is theBen Harris2006-12-09
| | | | | | | | | dominant format for print-oriented documents, but mostly because it's hard to mention pdfmark without having mentioned PDF already. Also mention pdfmark. [originally from svn r6975]
* Two of the bugs listed in the man page are out of date: Unicode andSimon Tatham2006-12-04
| | | | | | | | | character set support, and the HTML back end, have both been extensively revamped since that section was written, and I think neither of them is shoddy enough to warrant this sort of self-disparagement any more. [originally from svn r6959]
* It's conventional to use a minus sign rather than a hyphen to separateBen Harris2006-05-08
| | | | | | | the description from the name in the NAME section of a manpage. Halibut can do that now, so make use of that ability. [originally from svn r6664]
* Add a `--list-charsets' option to Halibut to enumerate canonical names of knownJacob Nevins2005-02-18
| | | | | | | | | character sets. (Also make libcharset `return_in_enum' values saner.) [originally from svn r5341] [this svn revision also touched charset,filter,timber]
* Add \versionid.Jacob Nevins2005-02-17
| | | | [originally from svn r5338]
* Changes/additions to input character set handling:Jacob Nevins2005-02-17
| | | | | | | | | | | | | | | | | - 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]
* We seem to have ended up with duplicate documentation of --man. Gone.Jacob Nevins2004-06-19
| | | | [originally from svn r4303]
* ... oh, except that minimal documentation might be helpful.Simon Tatham2004-04-14
| | | | [originally from svn r4075]
* I wrote the info backend _days_ ago. About time the manpage stoppedSimon Tatham2004-04-13
| | | | | | listing its absence as a bug :-) [originally from svn r4063]
* Forgot to mention the info backend in the man page.Simon Tatham2004-04-10
| | | | [originally from svn r4054]
* Ahem; let's have all the man page headings at the same level!Simon Tatham2004-04-08
| | | | [originally from svn r4045]
* Add a man page.Simon Tatham2004-04-08
[originally from svn r4042]