halibut/bk_ps.c, branch master My halibut tree Revamp of the Halibut error handling mechanism. 2012-08-29T18:13:11+00:00 Simon Tatham anakin@pobox.com 2012-08-29T18:13:11+00:00 1489dc15967970576d08f3f2b22c6e1c939bcbcf 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] 
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]
Allow a hastily selected subset of the output formats to also accept 2009-10-24T09:33:21+00:00 Simon Tatham anakin@pobox.com 2009-10-24T09:33:21+00:00 6c481aff452a0eed147fc73144b461fe7c263d9e "-" 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] 
"-" 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]
Make ps_token() more generally available and use it to improve the formatting 2007-02-06T23:01:42+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-06T23:01:42+00:00 b5a4f7b65579a789743e5c039c7286cc9d8e24a1 of Type 42 fonts. [originally from svn r7245] 
of Type 42 fonts.

[originally from svn r7245]
Add support for using TrueType fonts, including embedding in PostScript but 2007-02-03T14:02:21+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-03T14:02:21+00:00 62be4468c8d814e5f66e5c2c7dc21a865bd91be3 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] 
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]
Add support for PFB files. This seems to have caused me to completely 2007-01-27T20:47:41+00:00 Ben Harris bjh21@bjh21.me.uk 2007-01-27T20:47:41+00:00 72d22e8a1a1b47635e1b8da49ae703bde01228f2 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] 
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]
Overhaul of glyph-name handling in the paper backends. Before, we had 2007-01-06T17:32:34+00:00 Ben Harris bjh21@bjh21.me.uk 2007-01-06T17:32:34+00:00 30ca2bdcde0675a2d52a9decf9dce73e57fdcee1 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] 
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]
Tweak /OUT pdfmark generation -- PLRM suggests that constructing a large 2006-12-12T21:51:33+00:00 Ben Harris bjh21@bjh21.me.uk 2006-12-12T21:51:33+00:00 71f99d5b3a6361ee2fd937799293d9e5c18c4164 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] 
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]
Rough-and-ready line wrapping for PostScript, to keep us below the DSC-mandated 2006-12-12T00:13:59+00:00 Ben Harris bjh21@bjh21.me.uk 2006-12-12T00:13:59+00:00 4c2f461fc355561b93e611a636c7442514b354b1 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] 
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]
Explicitly set the title via pdfmark, since that allows us to put 2006-12-10T22:11:35+00:00 Ben Harris bjh21@bjh21.me.uk 2006-12-10T22:11:35+00:00 19ae561fd24807b29806a65eb974f8826f7cbbf9 in Unicode, which we can't (reliably) in %%Title. [originally from svn r6987] 
in Unicode, which we can't (reliably) in %%Title.

[originally from svn r6987]
Specify the /Border of /ANN pdfmarks correctly. 2006-12-07T14:00:12+00:00 Ben Harris bjh21@bjh21.me.uk 2006-12-07T14:00:12+00:00 dc9478059884bc1c21780bdefa6b340650711f3f [originally from svn r6968] 
[originally from svn r6968]