| Commit message (Collapse) | Author |
|---|
|
This was another valgrind-spotted uninitialised variable. And although
you'd think the 'filetype' field is unimportant for fonts that aren't
loaded from a file anyway, it is important, because bk_pdf.c emits
different code for creating font subsets of Type 1 and TrueType fonts
- i.e. it needs to know what type the font has _after_ it's loaded,
not just how to load it.
|
|
early and using it whenever we need the name of a non-standard glyph.
[originally from svn r7216]
|
|
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]
|
|
[originally from svn r7062]
|
|
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]
|
|
hard-coding it. No practical gain, since the hard-coded entries were correct,
but aesthetically better.
[originally from svn r7046]
|
|
the "fi" and "fl" ligatures to the built-in fonts, but doesn't add support
for reading ligature information from AFM files because that requires coping
with forward references to glyph names, which is tricky.
[originally from svn r7045]
|
|
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]
|
|
good free licence. Abide by its terms even though I'm not sure Halibut
is a derived work in law.
[originally from svn r6666]
|
|
[originally from svn r6665]
|
|
the AFM files in psdata.c. Also fix a couple of bugs that this revealed.
[originally from svn r4588]
|
|
from Adobe's official AFM files. These are expressed in integer multiples
of 1/1000 pt (well, 1/1000 of the design size of the font, actually, but that's
always a whole number of points), so use that as our internal unit rather
than 1/4096 pt. This doesn't seem to make a significant difference to
Halibut's output.
[originally from svn r4576]
|
|
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]
|
