| Commit message (Collapse) | Author |
|---|
|
Thanks to Paul Curtis for reporting that 'if (i != prev+1)' would be
undefined on the first pass through this loop, because prev was never
initialised beforehand. Initialise it to a safe value.
|
|
I'm not quite sure why I ever thought it was a good idea to have a
central variadic error() function taking an integer error code
followed by some list of arguments that depend on that code. It now
seems obvious to me that it's a much more sensible idea to have a
separate function per error, so that we can check at compile time that
the arguments to each error call are of the right number and type! So
I've done that instead.
A side effect is that the errors are no longer formatted into a
fixed-size buffer before going to stderr, so I can remove all the
%.200s precautions in the format strings.
[originally from svn r9639]
|
|
pass something that isn't necessarily an unsigned short.
[originally from svn r9493]
|
|
[originally from svn r9478]
|
|
"-" as a special file name meaning standard output. I've restricted
it to just those output formats which can predictably output only
one file, just for the sake of not having to faff too much with the
others.
Probably what I should have done for all of this would have been to
write a set of wrappers around fopen, fclose and everything in
between, and use them everywhere. Those wrappers would uniformly
detect "-" and convert it into stdin or stdout as appropriate, would
avoid fclosing those files for real when told to close them, and
would also be able to handle reading a little bit of data from the
start of a file and then pushing it all back even if the file were
not seekable (which would allow input.c to lose the ugly special
case whereby it can't currently read font files from standard
input).
[originally from svn r8729]
|
|
[originally from svn r8310]
|
|
We now detect ranges of glyphs mapped contiguously and use {begin,end}cidrange
for them, and also bunch together multiple characters and ranges in each
{begin,end}cid{char,range} pair.
[originally from svn r7263]
|
|
since that seems closer to being where it belongs.
[originally from svn r7262]
|
|
things without one.
[originally from svn r7261]
|
|
beautiful I've ever written, and xpdf turns out not to support the encoding
mechanism I've chosen, but it works in GhostScript so I'm not too unhappy for
now.
[originally from svn r7259]
|
|
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]
|
|
a separate dense array of glyph names for each font, and referenced glyphs
by indicies into that array, which meant that the array had to be set
up before we could generate any indices. Now we have an overall array of
glyph names, and use the same glyph indicies for all fonts. Some arrays
have had to turn into tree234s as a result.
[originally from svn r7061]
|
|
[originally from svn r6985]
|
|
fonts) may not be well handled, and may emit invalid PDF.
[originally from svn r6974]
|
|
[originally from svn r6952]
|
|
into its own function.
[originally from svn r6937]
|
|
silly, and eight isn't.
[originally from svn r6936]
|
|
[originally from svn r6931]
|
|
as recommended by the PDF spec.
[originally from svn r6923]
|
|
Halibut uses.
[originally from svn r6912]
|
|
objects and removing some surplus whitespace. This saves 40K in the Halibut
manual.
[originally from svn r6688]
|
|
so I don't have to press SPACE so much to get to the interesting part of the
file.
[originally from svn r6687]
|
|
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]
|
|
fonts in PDF output.
[originally from svn r6684]
|
|
to embed /FirstChar, /LastChar, /Widths or (soon) /FontDescriptor for them.
[originally from svn r6683]
|
|
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]
|
|
to skip unused code points.
[originally from svn r6673]
|
|
of the document. This means that (e.g.) gv displays the title correctly.
[originally from svn r6672]
|
|
putting one in each page, put a single one in the top-level page tree node.
This saves us all a few kilobytes in the Halibut manual.
[originally from svn r6671]
|
|
with a macro. halibut.ps and halibut.pdf are identical (modulo dates) over
this change.
[originally from svn r4564]
|
|
options from being processed in some circumstances.
[originally from svn r4329]
|
|
(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]
|
|
still doesn't _work_ properly if there aren't any contents entries,
but it's a start.
[originally from svn r4250]
|
|
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]
|
