| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
executable array is likely to use lots of stack space, which might be bad on
Level 1 interpreters, so use the same mechanism as for other pdfmarks and
have a procedure that does nothing if pdfmark isn't defined.
[originally from svn r6995]
|
| |
|
|
|
|
|
|
| |
255 characters per line (excluding newline characters). In fact, it tries to
keep us below 80 characters so as to make the PostScript more readable (and
demonstrate that it's working).
[originally from svn r6993]
|
| |
|
|
|
|
| |
in Unicode, which we can't (reliably) in %%Title.
[originally from svn r6987]
|
| |
|
|
| |
[originally from svn r6968]
|
| |
|
|
|
|
|
| |
pdfmark, specifically by having the dummy versions of "p", "x", and "u" pop
their arguments rather than leaving them on the stack to cause trouble.
[originally from svn r6956]
|
| |
|
|
| |
[originally from svn r6952]
|
| |
|
|
|
|
| |
Halibut's output 7-bit clean, which seems the best approach in PostScript.
[originally from svn r6950]
|
| |
|
|
| |
[originally from svn r6949]
|
| |
|
|
| |
[originally from svn r6938]
|
| |
|
|
| |
[originally from svn r6689]
|
| |
|
|
|
|
| |
a few K and a lot of calls to scalefont and setfont, which is probably good.
[originally from svn r6686]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
we've got are wrong, things are going to look horrible either way, so
we may as well apply minimal effort.
[originally from svn r4580]
|
| |
|
|
|
|
|
| |
in the new font dictionary for the Metrics entry. This is mentioned in the
first edition of the Red Book, but not the second.
[originally from svn r4577]
|
| |
|
|
|
|
|
| |
"restore". Quite how GhostScript managed not to give an error on this I
don't know.
[originally from svn r4565]
|
| |
|
|
|
|
|
| |
with a macro. halibut.ps and halibut.pdf are identical (modulo dates) over
this change.
[originally from svn r4564]
|
| |
|
|
|
|
|
| |
enforces page independence, avoids leaking VM on level 1 interpreters, and
speeds things up to boot.
[originally from svn r4561]
|
| |
|
|
|
|
|
|
| |
In particular, use the operand stack to hold "x" and "y", and use a dictionary
lookup to switch based on the type of "x". This also seems to give a slight
speed increase.
[originally from svn r4553]
|
| |
|
|
|
|
|
|
|
| |
* Use "/arraytype" etc rather than "[] type" etc. Should be faster and not fill
local VM with empty arrays.
* Use "bind" on the procedure, since it's conventional and will probably
help speed too.
[originally from svn r4552]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
current since 1990. The only obvious change from this is that gv now displays
the document title.
There's a slight bug here at the moment in that the backend emits
%%DocumentNeededResource and %%IncludeResource for each subfont of a
PostScript font, even if that PostScript font has been requested already.
This is wasteful but, as far as I can see, not actually disallowed, and
is easier than de-duping the font list.
[originally from svn r4551]
|
| |
|
|
|
|
| |
options from being processed in some circumstances.
[originally from svn r4329]
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
[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]
|