| Commit message (Collapse) | Author |
|---|
|
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]
|
|
unsigned int, after a correspondent mentioned that DJGPP produces a
very scary warning about integer promotion making use of the former
in va_arg non-portable. Whether or not that's standards-justifiable,
it's certainly the case that we were casting _to_ wchar_t from
unsigned int in all cases of this error actually being used, so the
simplest thing is just to transfer the number through va_arg as
unsigned.
[originally from svn r8112]
|
|
that can't be resolved (apart from warning about it).
[originally from svn r7800]
|
|
[originally from svn r7269]
|
|
(which triggers err_infonodechar with fpos==NULL).
[originally from svn r7044]
|
|
don't know how to write out a .CHM directly, but I am at least able
to have the HTML back end write out the three auxiliary files which
enable a .CHM to be generated using the MS HTML Help compiler.
[originally from svn r6991]
|
|
fonts) may not be well handled, and may emit invalid PDF.
[originally from svn r6974]
|
|
commands, allowing the fixed words "Contents" and "Index" generated
in various output formats to be reconfigured into other languages.
[originally from svn r6724]
|
|
loading AFM files, we recognise them by name, and we can't embed fonts in
the output (which is also invalid, though accepted by xpdf, in the PDF case).
Oh, and there's no documentation. Still, it's a start.
[originally from svn r6681]
|
|
load font metrics dynamically, we're restricted to the fonts whose metrics
are compiled into Halibut. Font structures aren't reused when the same
font is specified twice, nor are unused fonts removed from the output.
Finally, the default configuration overflows lines in the manual, but this
would need a change to Halibut's grammar to fix.
Still, what's there works.
[originally from svn r6667]
|
|
points out that it's perfectly possible to generate an empty
paragraph using legal Halibut syntax: a paragraph containing nothing
but a \#{...} comment will do the job, and is quite likely to happen
if you've commented out a load of Halibut code. Therefore, an empty
paragraph is now silently ignored rather than being an error
condition in itself; if you create an empty paragraph due to it
containing an unrecognised directive, then you'll get an error for
_that_ and only that.
[originally from svn r6361]
|
|
in it, if the input paragraph contained (say) an unrecognised
control command and nothing else. Such paragraphs can confuse back
ends later on, so input.c should refrain from generating them. Added
a check and a polite error message (just in case the user manages to
generate an empty paragraph using otherwise legal syntax).
[originally from svn r5629]
|
|
Halibut will output fragment names in all specified formats. (I forget now
precisely why I thought this was necessary, but it seems potentially useful.)
Also ensure that legal fragment names are generated even if none of the
characters from the original turn out to be legal (e.g., %k with an entirely
numeric keyword), and correct an untruth I inserted in the documentation of
this.
(This commit hits more than just the HTML backend as I've generalised an error
message, and fixed a fault in the info backend's error handling while there.)
[originally from svn r5457]
|
|
- 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]
|
|
an integer charset ID.
[originally from svn r4317]
|
|
fiddle with various small aspects of the output so that it actually
validates in all supported flavours.
[originally from svn r4307]
|
|
terms (intentionally) differing only in case, which were being
silently folded into one by the case-insensitive index tag
comparison. Halibut now warns in this situation (but then folds them
anyway, which I think is better than silently generating an index
containing many case-distinct forms of the same word - I imagine
it's very easy to do that by mistake). The manual has been fixed to
explicitly define distinct keywords (in the case I spotted and in
five other cases picked up by the new warning!), and also documents
this issue and how to work with it.
[originally from svn r4279]
|
|
necessary since the whole point of \c should be that the user wants
to exercise exact control over the glyphs used, and forbidding it
has the useful effect of relieving some backends of having to make
difficult decisions: it means the text backend doesn't have to nest
two pairs of identical quotes, and the paper backends don't have to
downgrade their quote characters if (as is perfectly plausible) the
fixed-pitch font doesn't support the same range as the body text
fonts.
[originally from svn r4277]
|
|
configurable emphasis characters, various other configurable bits
which have been marked FIXME in the code for a while, and also to
warn when a code paragraph line is too long (because that was the
only other thing labelled FIXME). Fallback options are implemented,
and defaults set accordingly. A UTF-8 text output file now looks
like proper UTF-8.
[originally from svn r4128]
|
|
used for converting command-line -C directives into Unicode; it's
used for outputting Unicode strings to stderr in error messages; and
it's used as the default character set for input files (although I'd
be inclined to recommend everyone use \cfg{input-charset} in all
their source files to ensure their portability).
[originally from svn r4114]
|
|
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]
|
|
items of the form `* stuff: Section 1.2.' are parsed by standalone
info as `Section 1.2' followed by a period, but are parsed by other
readers as `Section 1' followed by a period and then some spare
text. Therefore, I've changed strategy, and the index is now full of
*Note cross-references rather than menu items. On the plus side,
this means there are no longer any special characters which we can't
tolerate in an index entry; on the minus side, my shiny new
infrastructure for tracking the filepos of index entries is now
rendered pointless. I'll leave it in, though, since it may come in
handy again.
[originally from svn r4053]
|
|
and index terms (the Info format doesn't like them). In the course
of this I've had to introduce some infrastructure for carrying a
filepos forward from the definition of every RHS index term so that
a particular backend can provide a usefully localised report of
which index term had a problem.
[originally from svn r4051]
|
|
appear to be used to automatically construct /usr/info/dir.
[originally from svn r4049]
|
|
directives to be supplied on the Halibut command line.
[originally from svn r4013]
|
|
[originally from svn r3978]
|
|
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]
|
|
[originally from svn r1800]
|
|
heapsort. This makes the code much simpler for a start, but the main
reason is so that we can spot duplicate keywords as we go along
rather than having to wait until the end of input processing.
[originally from svn r1489]
|
|
sections. Useful if another program needs to jump to a particular
topic. (Really we should support the proper CTXOMAP / HELP_WM_HELP
system for doing this, but I don't like numeric IDs; you'd have to
parse a bunch of #defines in order to sensibly synchronise the IDs
between help file and code.)
[originally from svn r1457]
|
|
user doesn't skip a heading level (\H before any \C or \A, or \S
straight after \C with no intervening \H). The precise criterion is
that when creating section a.b.c.d, sections a.b.c, a.b and a should
already exist. This ensures the section tree really is a properly
formed tree with no missing nodes.
[originally from svn r1329]
|
|
[originally from svn r828]
|
|
[originally from svn r252]
|
|
[originally from svn r242]
|
|
[originally from svn r240]
|
|
[originally from svn r238]
|
|
[originally from svn r220]
|
|
[originally from svn r200]
|
|
[originally from svn r193]
|
|
[originally from svn r187]
|
