| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
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]
|
