| 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.
|
|
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]
|
|
Also from J. Lewis Muir.
[originally from svn r10213]
|
|
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]
|
|
\cfg{paper-contents-margin}. Also correct the spelling of the
former.
[originally from svn r8424]
|
|
[originally from svn r8320]
|
|
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]
|
|
[originally from svn r7799]
|
|
in the Info backend, with the defaults chosen to match what Emacs
recognises and renders prettily.
[originally from svn r7452]
|
|
in a Roman font. Follow suit.
[originally from svn r7450]
|
|
[originally from svn r7284]
|
|
fonts is difficult.
[originally from svn r7281]
|
|
[originally from svn r7248]
|
|
(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]
|
|
[originally from svn r7178]
|
|
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]
|
|
rewrite the Type 1 font support, and I'm sure the result is more complex
than it needs to be, but it seems to work correctly, so I shouldn't
complain.
[originally from svn r7175]
|
|
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]
|
|
[originally from svn r6990]
|
|
[originally from svn r6977]
|
|
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]
|
|
the Halibut manual. They turn out to be \cfg directives with
multiple braced sections after them. The obvious thing to do for
legibility would be to wrap those sections by putting newlines
between } and {, but that isn't legal in the Halibut syntax.
Therefore, it is now :-) For paragraph types which don't have any
body text (such as \cfg), we are now lenient about whitespace
between multiple keywords. So I can fix the docs so they don't go
over the limit, and be confident that the fixed version is still
technically accurate.
[originally from svn r6970]
|
|
worked, I happened to notice this typo. I think Wikipedia might have
permanently removed my ability to read any document for any purpose
without spotting at least one error in it.
[originally from svn r6958]
|
|
[originally from svn r6913]
|
|
commands, allowing the fixed words "Contents" and "Index" generated
in various output formats to be reconfigured into other languages.
[originally from svn r6724]
|
|
accepted length of A4 paper in the PostScript/PDF world, so use it as
our default.
[originally from svn r6669]
|
|
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]
|
|
is processed by nroff, the rule is made up of \cfg{man-rule}
characters (same defaults as \cfg{text-rule}).
[originally from svn r6651]
|
|
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]
|
|
[originally from svn r5346]
|
|
[originally from svn r5338]
|
|
[originally from svn r5334]
|
|
[originally from svn r5333]
|
|
put an AppleTitle tag in only one of a set of output HTML files.
[originally from svn r5192]
|
|
of bk_paper.c 1.29 [r4330] appears to have fixed this.
[originally from svn r4432]
[r4330 == 8aac8532019ac6cee701d48ceb35473280219a0e]
|
|
shorthand command \cq{foo}.
[originally from svn r4327]
|
|
Contains many FIXMEs, both for incomplete documentation and incomplete
code.
Couple of other minor tweaks elsewhere.
[originally from svn r4304]
|
|
WinHelp, man, and info backends, and organisation into sections (now that
we have rather more directives documented). I've not changed the actual
text much if at all.
[originally from svn r4301]
|
|
[originally from svn r4300]
|
|
to be quoted.
[originally from svn r4299]
|
|
[originally from svn r4297]
|
|
- \cfg{quotes}
- text, info, man, and winhelp backends:
- charset
- quotes and bullets
- various WinHelp miscellanea
Could stand some rearrangement and expansion, plus I've yet to address the
paper or HTML backends.
[originally from svn r4295]
|
|
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]
|
|
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]
|
|
[originally from svn r4131]
|
|
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]
|
|
collection of minor edits for clarity, and also quite a few intended
to keep down the length of lines in code paragraphs (because Courier
is not just a thoroughly ugly font but is also WAY TOO WIDE).
[originally from svn r4076]
|
|
[originally from svn r4075]
|
|
[originally from svn r4052]
|
