| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
PDFDocEncoding or UTF-16BE. (The PDF specification's index is
terribly bad; I looked under various obvious things such as
`character set' and `string literal' with no success, and I didn't
manage to find out what character set metadata string literals were
intended to be interpreted in until I discovered from another source
that the encoding was called PDFDocEncoding, and _then_ I was able
to look that up in the index. They should have been using Halibut! :-)
[originally from svn r4101]
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
of the same font and position designations. Reduced the size of the
Halibut manual PDF to less than half what it started out as, and the
PS one to more like a third of its original size.
[originally from svn r4083]
|
| |
|
|
|
|
| |
output files.
[originally from svn r4079]
|
| |
|
|
|
|
|
|
|
|
| |
correspond exactly to a source paragraph. Should allow me to create
multiple printed paragraphs from the same source paragraph (i.e. a
contents entry for each heading in addition to the heading itself),
and invent entirely new printed paragraphs of my own (e.g. for index
entries).
[originally from svn r4068]
|
| |
|
|
| |
[originally from svn r4067]
|
| |
|
|
| |
[originally from svn r4065]
|
| |
|
|
|
|
|
| |
document, and references to external URLs for which acroread will
start a web browser.
[originally from svn r4060]
|
|
|
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]
|
