| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit updates the libcharset submodule to incorporate the
autotools-ification that I just pushed to that subproject, and builds
on it by replacing Halibut's own makefile system similarly with an
autotools setup.
The new Makefile.am incorporates both of the old Makefile and
doc/Makefile, so a single run of 'make' should now build Halibut
itself and all the formats of its own documentation, which also means
that the automake-generated 'make install' target can do the right
thing in terms of putting an appropriate subset of those documentation
formats in the assorted installation directories.
The old Makefiles are gone, as is release.sh (which is now obsolete
because autotools's 'make dist' doesn't do anything obviously wrong).
The bob build script is comprehensively rewritten, but should still
work - even the clang-based Windows build can use the
autotools-generated makefile system, provided I do the libcharset
build with a manual override of bin_PROGRAMS to prevent it trying to
build the libcharset supporting utilities (which are not completely
Windows-portable).
|
| |
|
|
|
| |
Thanks to Leah Neukirchen for pointing out that it was left out of
that special-case rule.
|
| |
|
|
|
|
| |
Or rather, clang in MS-targeted code generation but still with the
Unix-style command line, which lets me use the existing Makefile with
almost no change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 general routines for analysing a buffer into an LZ77ish stream of
literals and matches, and for constructing a Huffman tree in canonical
format, now live in their own source files so that they can be reused
for other similar compression formats. Deflate-specific details like
the exact file encoding are left in deflate.c.
|
| |
|
|
|
| |
Now you can 'make install prefix=/some/previously/nonexistent/path'
and have all the necessary subdirs created for you.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A long time ago, it seemed like a good idea to arrange that binaries
of Halibut would automatically cease to identify themselves as a
particular upstream version number if any changes were made to the
source code, so that if someone made a local tweak and distributed the
result then I wouldn't get blamed for the results. Since then I've
decided the whole idea is more trouble than it's worth, so I'm
retiring it completely.
[originally from svn r10254]
|
| |
|
|
|
|
| |
Watson.)
[originally from svn r8422]
|
| |
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
in the main version. The one missing thing is the fancy new LZ77
compressor in misc/libcode/lz77.c, in whose stability I'm not yet
confident enough to consider it ready for prime-time.
[originally from svn r6967]
|
| |
|
|
| |
[originally from svn r6931]
|
| |
|
|
|
|
| |
producing output on stdout even in -c mode.
[originally from svn r6707]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
| |
anything in it! In its current form it presents the portability
hazards of an empty structure and an empty source file. Therefore,
I'm removing it; if I ever have a clear idea of what a user style
mechanism ought to look like, it might make a reappearance, but
don't hold your breath.
[originally from svn r6453]
|
| |
|
|
|
|
|
|
| |
`install' etc) don't get confused by the existence of a file with
the same name. Required in particular for `make install' on OS X,
since otherwise its case-insensitive fs gets confused by INSTALL.
[originally from svn r5189]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
into a subdirectory of `halibut'. It wasn't very good anyway (since
it insisted on loading via an unauthenticated svn:// URL). The
Halibut makefile now expects _either_ a subdir `charset', _or_ a
directory called `charset' as a sibling of `halibut', and will work
with the first of those that it finds. A new release script arranges
to provide the former in source tarballs (so that building if you're
an ordinary user is just as simple as it always was).
[originally from svn r4808]
|
| |
|
|
|
|
| |
isn't GNU Make.
[originally from svn r4548]
|
| |
|
|
|
|
| |
putty/mkunxarc.sh) - apparently this upsets some older gzips (1.2.4).
[originally from svn r4431]
|
| |
|
|
|
|
|
|
|
| |
garbage' when handling a GNU tar archive. Using the -o flag when
building the tar file creates an archive which the user said WinZip
had no trouble with, and GNU tar seems just as happy with that, so
`make release' now uses -o.
[originally from svn r4323]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 r4267]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
characters in order to wrap and align them properly. Therefore, they
should be using wcwidth(). So here are a couple of wrappers on
wcwidth(), one which filters out the Unicode characters not
representable in the target charset, and one which converts _from_ a
charset to Unicode before calling wcwidth(). bk_text and bk_info
should now align correctly even in the face of unsupported
characters and Japanese.
[originally from svn r4116]
|
| |
|
|
|
|
|
|
|
| |
CVSROOT/modules, so anyone with a checked-out copy of Halibut will
unfortunately need to do `cvs co' again.)
[originally from svn r4088]
[added anachronistic .gitmodules so that past revisions can be checked out]
[this svn revision also touched charset,timber]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
the Unix PuTTY archive, to automatically generate version numbers
for Halibut release builds.
[originally from svn r4044]
|
| |
|
|
| |
[originally from svn r4043]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
output from running Halibut on a test input file.
[originally from svn r1833]
|
| |
|
|
| |
[originally from svn r1800]
|
| |
|
|
|
|
|
|
|
|
| |
hierarchical topic navigation (menus at the bottom of non-leaf
topics, and the Up button) and index support; also I want to give
users the ability to specify context IDs for particular topics. Oh,
and I haven't found a plausible way to express a horizontal rule in
either .RTF or .HLP format. But everything else appears to be there.
[originally from svn r1447]
|
| |
|
|
|
|
| |
tree234 routines; they will be useful in the WinHelp stuff at least.
[originally from svn r1444]
|
| |
|
|
| |
[originally from svn r828]
|
| |
|
|
| |
[originally from svn r809]
|
| |
|
|
| |
[originally from svn r251]
|
| |
|
|
| |
[originally from svn r240]
|
| |
|
|
| |
[originally from svn r238]
|
| |
|
|
| |
[originally from svn r200]
|
| |
|
|
| |
[originally from svn r193]
|
| |
|
|
| |
[originally from svn r187]
|
|
|
[originally from svn r22]
|
