| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
I ran into this as a knock-on effect from having misspelled a section
name identifier (i.e. I had a \k{nonexistent-name} in my document).
Before I fix the document, I should fix the segfault!
|
| |
|
|
|
|
| |
Naturally, after calling the previous commit '1.2', someone had to
instantly find a bug that shows up in the simplest possible example
Halibut invocation :-(
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
No functional change, but this opens the way to have further sets of
config directives that parallel the \cfg{html-foo} family but with
different prefixes in place of 'html'. The previous code to treat
prefixes 'html' and 'xhtml' the same was not general enough because it
depended on the coincidence that the former is a suffix of the latter.
|
| |
|
|
|
|
|
|
|
| |
I introduced this in commit b3db1cce3, which I hadn't really meant to
push at all yet (it's groundwork for a new feature that's still in
development), but which I had absentmindedly left lying around in my
usual checkout directory when the time came to do 84ed4f994, and which
got pushed as a side effect without having been quite fully tested
yet. Ahem.
|
| | |
|
| |
|
|
|
|
|
|
| |
I had no idea that was a thing HTML Help could do at all, let alone
that .chm files could enable or disable it via a flag! But Tino
Reichardt sent in a patch which sets one extra bit in a flags word in
the .hhp file, and despite 'chmspec' not mentioning that bit at all,
it does indeed seem to do something useful.
|
| |
|
|
|
|
| |
Turns out we can get a null pointer passed through from the front end,
if the input file was erroneous in some way, so we should do fallback
processing if so (exactly what doesn't matter much) rather than crash.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch due to J. Lewis Muir, who points out that the HTML backend's
current policy of _always_ disabling the TOC in single-file mode is
excessively harsh: in a long or formal enough document, you might
still want a TOC to make navigating around within the file easier,
even if it's not necessary to use it to get between multiple files.
So this change removes the unconditional prohibition against TOCs in
single-file documents, but they're still disabled by default, because
a single file counts as a leaf file and the existing default settings
disable TOCs in leaf files anyway. So if you do want a TOC in a single
file, you can reconfigure 'html-leaf-contains-contents' to true.
[originally from svn r10212]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this a couple of times in Halibut markup recently (in particular, it's
handy to have a typographical distinction between 'this term is
emphasised because it's new' and 'this term is emphasised because I
want you to pay attention to it'), so here's an implementation,
basically parallel to \e.
One slight oddity is that strong text in headings will not be
distinguished in some output formats, since they already use bolded
text for their headings.
[originally from svn r9772]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
[originally from svn r8743]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"-" as a special file name meaning standard output. I've restricted
it to just those output formats which can predictably output only
one file, just for the sake of not having to faff too much with the
others.
Probably what I should have done for all of this would have been to
write a set of wrappers around fopen, fclose and everything in
between, and use them everywhere. Those wrappers would uniformly
detect "-" and convert it into stdin or stdout as appropriate, would
avoid fclosing those files for real when told to close them, and
would also be able to handle reading a little bit of data from the
start of a file and then pushing it all back even if the file were
not seekable (which would allow input.c to lose the ugly special
case whereby it can't currently read font files from standard
input).
[originally from svn r8729]
|
| |
|
|
|
|
| |
\cfg{html-section-shownumber}{n} undefined.
[originally from svn r7929]
|
| |
|
|
|
|
|
|
|
| |
both the back ends which currently support that, to leave out
chapter and section numbers totally in section headings. Can be
useful for publishing man pages (which don't normally want section
numbers) on the web.
[originally from svn r7892]
|
| |
|
|
|
|
|
|
| |
(This doesn't affect any of the source texts I know about.)
Also add <link rel="up">, even in the cases where it's just the same as
<link rel="ToC">. (This does.)
[originally from svn r7193]
|
| |
|
|
|
|
|
| |
\cfg{html-rellinks}, and it generally seems to be a Good Thing, so I've
turned it on by default. (The lurkers support me in u2u.)
[originally from svn r7188]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Off by default for now, but I don't intend that it should stay this way; they
seem useful and harmless. I just want to check a few more browsers to ensure
they don't do anything obnoxious with them.
So far I've only seen lynx and links do something with them (provide toolbars).
iCab and some Mozilla derivatives/extensions are also alleged to do this; Opera
is said to allow PgDn type browsing through the entire set of pages; and
Mozilla is rumoured to use the "next" link for prefetching.
[originally from svn r7177]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CHM, and added the toolbar buttons for this.
Also rationalised the other options a bit:
- added Forward button (since we have Back);
- removed Locate/Sync (since we have auto-sync enabled for the ToC);
- removed Stop and Refresh (mostly a waste of space for help, but still
available from the Options menu if users really want them);
- enabled advanced facilities on the Search tab (search within results, etc).
All this seems to have had no obvious ill effects (tested on Win98), although
the resulting CHM file is slightly bigger (~3kbyte, <1%).
[originally from svn r7176]
|
| |
|
|
|
|
| |
any, I reckon.
[originally from svn r6994]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
commands, allowing the fixed words "Contents" and "Index" generated
in various output formats to be reconfigured into other languages.
[originally from svn r6724]
|
| |
|
|
|
|
| |
segfault if they were unable to open their output files.
[originally from svn r6704]
|
| |
|
|
|
|
|
| |
`anonfrag' should be a char[] rather than a char *, or else lenof()
will give the wrong answer.
[originally from svn r5477]
|
| |
|
|
|
|
|
|
|
| |
conceptually const but not declared as such. Halibut is now back to
the practically-speaking-pointless but rather satisfying status of
having no global writable data whatsoever :-)
[originally from svn r5476]
[this svn revision also touched charset,filter,timber]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
| |
all HTML flavours).
Also add newlines to the contents output so that the source is vaguely
legible.
Couple of extra comments in the code.
[originally from svn r5453]
|
| |
|
|
| |
[originally from svn r5350]
|
| |
|
|
| |
[originally from svn r5348]
|
| |
|
|
|
|
| |
name.
[originally from svn r5336]
|
| |
|
|
|
|
| |
sections looking for local configuration data.
[originally from svn r5196]
|
| |
|
|
|
|
| |
put an AppleTitle tag in only one of a set of output HTML files.
[originally from svn r5192]
|
| |
|
|
|
|
| |
have any real effect).
[originally from svn r4401]
|
| |
|
|
| |
[originally from svn r4321]
|
| |
|
|
|
|
| |
an integer charset ID.
[originally from svn r4317]
|
| |
|
|
| |
[originally from svn r4316]
|
| |
|
|
| |
[originally from svn r4315]
|
| |
|
|
|
|
| |
HTML backend.
[originally from svn r4314]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
HTML backend. After an argument with James in which it transpired
that we each thought it was absolutely obvious which one
\cfg{html-charset} ought to map to, and each of us was thinking of a
different one, I've decided that this implies it _isn't_ obvious,
and hence there is no single \cfg{html-charset} directive at all.
Instead, we have \cfg{html-restrict-charset} and \cfg{html-output-
charset}, and any naive user who `just wants to change character
set' is just going to have to RTFM and figure out which one they
mean.
[originally from svn r4313]
|
| |
|
|
| |
[originally from svn r4308]
|
| |
|
|
|
|
|
| |
fiddle with various small aspects of the output so that it actually
validates in all supported flavours.
[originally from svn r4307]
|
| |
|
|
|
|
| |
bibliography entries.
[originally from svn r4305]
|
| |
|
|
|
|
|
|
|
| |
their anchors generated. Index bugs of this type can be terribly
subtle and go unnoticed for ages; I'm lucky Jacob spotted the first
one of the type, but I'm now going to be careful to avoid any
further ones.
[originally from svn r4293]
|
| |
|
|
|
|
| |
titles. Ahem.
[originally from svn r4292]
|
| |
|
|
|
|
| |
fragment name twice for any reason.
[originally from svn r4291]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(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]
|
