| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this a couple of times in Halibut markup recently (in particular, it's
handy to have a typographical distinction between 'this term is
emphasised because it's new' and 'this term is emphasised because I
want you to pay attention to it'), so here's an implementation,
basically parallel to \e.
One slight oddity is that strong text in headings will not be
distinguished in some output formats, since they already use bolded
text for their headings.
[originally from svn r9772]
|
| |
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
of Type 42 fonts.
[originally from svn r7245]
|
| |
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
and apply it to code paragraphs.
[originally from svn r7069]
|
| |
|
|
| |
[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]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
fonts) may not be well handled, and may emit invalid PDF.
[originally from svn r6974]
|
| |
|
|
| |
[originally from svn r6952]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
with a macro. halibut.ps and halibut.pdf are identical (modulo dates) over
this change.
[originally from svn r4564]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
the fine details right.
[originally from svn r4072]
|
| |
|
|
| |
[originally from svn r4069]
|
| |
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
bonuses for breaking in particular places. (For example, it's
especially bad to break just after a heading, and especially good to
break just before one.)
[originally from svn r4064]
|
| |
|
|
|
|
|
|
| |
font selection in headings, mentioning section numbers, bullets,
list item numbers, code paragraphs etc). The PS/PDF output now
actually looks like the document it's supposed to be :-)
[originally from svn r4061]
|
| |
|
|
|
|
|
| |
document, and references to external URLs for which acroread will
start a web browser.
[originally from svn r4060]
|
| |
|
|
|
|
|
| |
of semantics as to whether a `last' pointer pointed to the last
relevant thing in a list, or the one beyond that. Oops.
[originally from svn r4059]
|
|
|
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]
|
