| Commit message (Collapse) | Author |
|---|
|
This is a function I should have introduced a lot earlier while
writing the CHM output code, because I ended up with quite a lot of
annoying loops to add zero-padding of various sizes by going round and
round on the one-byte rdaddc().
|
|
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]
|
|
was causing emphasis to be broken (particularly noticeable in text-like
backends). There are some instances of this in the PuTTY manual, for instance.
Unfortunately, \k references in similar situations still aren't quite right,
but fixing that will be more involved, and I haven't found any instances
yet.
[originally from svn r7049]
|
|
[originally from svn r6931]
|
|
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]
|
|
(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]
|
|
somewhat roundabout and arse-backwards sort of way, due to some
other properties of the sort that I rather wanted to maintain. But I
hope it should still do some good.)
[originally from svn r4119]
|
|
merely traverses a list of words, and main() takes responsibility
for applying it to each paragraph in the document. This is so that
it can _also_ be applied to the display form of each index entry,
which Jacob spotted wasn't previously being done.
[originally from svn r4117]
|
|
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]
|
|
an enormous amount of preprocessing and differ only in their final
output form, I've introduced a new type of layer called a
`pre-backend' (bk_paper.c is one). This takes all the information
passed to a normal backend and returns an arbitrary void *, which is
cached by the front end and passed on to any backend(s) which state
a desire for the output of that particular pre-backend. Thus, all
the page layout is done only once, and the PS and PDF backends
process the same data structures into two output files.
Note that these backends are _very_ unfinished; all sorts of vital
things such as section numbers, list markers, and title formatting
are missing, the paragraph justification doesn't quite work, and
advanced stuff like indexes and PDF interactive features haven't
even been started. But this basic framework generates valid output
files and is a good starting point, so I'm checking it in.
[originally from svn r4058]
|
|
without going through the .texi source stage. A few things left to
do, notably documentation, but the basics all seem to be there.
[originally from svn r4047]
|
|
[originally from svn r4004]
|
|
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]
|
|
like a typographical Bad Plan, but they work OK in some types of
document such as a FAQ.)
[originally from svn r1324]
|
|
its line. Real typesetters in practice don't appear to care much
about this, and the lengths the algorithm has to go to to avoid it
tend to end up looking even uglier.
[originally from svn r1322]
|
|
optimal dynamic one used by the likes of TeX. Woo.
[originally from svn r1288]
|
|
[originally from svn r274]
|
|
[originally from svn r252]
|
|
between emphasis _like_ _this_ and _like this_
[originally from svn r245]
|
|
[originally from svn r240]
|
|
[originally from svn r238]
|
|
[originally from svn r237]
|
|
[originally from svn r214]
|
|
[originally from svn r187]
|
