| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
not yet in PDF. There's a lot of cleaning up to be done, especially in the
area of error, but I think it would be better committed gradually.
[originally from svn r7198]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
This prevents one having Halibut files that begin "StartFontMetrics",
"%!FontType1-", or "%!PS-AdobeFont-", but I doubt that will be a great
hardship.
[originally from svn r6960]
|
| |
|
|
|
|
|
|
| |
technically incorrect, though it works perfectly well with xpdf. To do
it properly requires actually parsing the unencrypted part of a Type 1
font, which will be a bit tedious in C.
[originally from svn r6685]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
in future, add `-ansi -pedantic' to the Halibut default compile
options and fix the few resulting warnings (mostly signed/unsigned
char mismatches and commas at the ends of enums). The one remaining
warning I'm still seeing is `missing initializer' for the big table
in charset/iso2022.c, but I think the code genuinely is more
readable this way, and I haven't found a gcc option to disable that
specific warning.
[originally from svn r6458]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
\}), making it difficult to put CSS fragments in HTML configuration.
[originally from svn r5193]
|
| |
|
|
|
|
|
| |
across files (defining a macro in one source file and invoking it in
a later one).
[originally from svn r4803]
|
| |
|
|
|
|
| |
macro expansions.
[originally from svn r4489]
|
| |
|
|
|
|
| |
shorthand command \cq{foo}.
[originally from svn r4327]
|
| |
|
|
|
|
| |
an integer charset ID.
[originally from svn r4317]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(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]
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
8859-*, UTF-8, or a variety of more fun encodings including various
multibyte ones.
[originally from svn r4095]
|
| |
|
|
|
|
|
|
| |
Halibut is now capable of reading the old NASM manual with only
minor modifications, and probably doing a much better job of
formatting it than rdsrc.pl ever did. (Certainly much _faster_!)
[originally from svn r4081]
|
| |
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
| |
a single newline) immediately after their opening brace; this was
causing a normal paragraph to be started, thus making it fiddly and
annoying to arrange the first paragraph of a \lcont to be a code
para or anything else special. Now fixed.
[originally from svn r4005]
|
| |
|
|
| |
[originally from svn r4003]
|
| |
|
|
|
|
|
|
|
| |
zero-width delimiter between a macro invocation and text beyond it,
so that you can define (say) a macro which expands to a Euro sign
and then write `\eur\.2500' to avoid having space between the Euro
sign and the number.
[originally from svn r3982]
|
| |
|
|
|
|
|
|
|
|
| |
any ordinary displayable paragraph(s) appearing before the first
chapter heading, meaning in particular that you can put lists, code
paragraphs etc in preambles. Of course, `\preamble' is still
supported for backwards compatibility, but it's now a zero-effect
paragraph marker.
[originally from svn r3981]
|
| |
|
|
| |
[originally from svn r3978]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
markup feature: a \c line in a code paragraph can now be followed by
an optional \e line indicating emphasised bits of its preceding \c.
This allows discretionary bolding and (italic/underline) emphasis
within code paragraphs, but without introducing an escape character
or breaking any existing input files. Users are warned that not all
backends are required to actually render these hints, and so they
should avoid depending on them 100% to convey semantic information
unless they know they're writing for a restricted range of backends.
[originally from svn r3965]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
thingy, which seems moderately cool and has reported a few very
small memory leaks. Now apparently fixed.
[originally from svn r1863]
|
| |
|
|
|
|
|
| |
blank-line separators (config directives visually _want_ to be in a
single chunk).
[originally from svn r1837]
|
| |
|
|
| |
[originally from svn r1800]
|
| |
|
|
|
|
|
|
| |
poorly; mostly it just treated \r as whitespace, and the only time
it actually suffered was at the end of a line in a code paragraph).
Should now be fixed.
[originally from svn r1492]
|
| |
|
|
|
|
|
| |
near-complete functionality. All that's missing now is indexing and
horizontal rules.
[originally from svn r1449]
|
| |
|
|
|
|
| |
tree234 routines; they will be useful in the WinHelp stuff at least.
[originally from svn r1444]
|
| |
|
|
| |
[originally from svn r1321]
|
| |
|
|
| |
[originally from svn r810]
|
| |
|
|
|
|
| |
in text output. Now all aux fields are carefully zeroed when not used
[originally from svn r307]
|
| |
|
|
| |
[originally from svn r276]
|
| |
|
|
| |
[originally from svn r275]
|
| |
|
|
| |
[originally from svn r274]
|
| |
|
|
| |
[originally from svn r252]
|
| |
|
|
| |
[originally from svn r250]
|
| |
|
|
| |
[originally from svn r248]
|
| |
|
|
| |
[originally from svn r246]
|
| |
|
|
|
|
| |
between emphasis _like_ _this_ and _like this_
[originally from svn r245]
|
| |
|
|
| |
[originally from svn r242]
|
| |
|
|
| |
[originally from svn r241]
|
| |
|
|
| |
[originally from svn r240]
|
| |
|
|
| |
[originally from svn r238]
|
| |
|
|
| |
[originally from svn r237]
|
