| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
(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]
|
|
|
[originally from svn r22]
|
