halibut/in_pf.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]
When loading a Type 1 font, remember to terminate the linked list we load 2007-02-03T14:05:32+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-03T14:05:32+00:00 1e92eef2b89afc4330652db964daf20e0efa84d3 it into. [originally from svn r7199] 
it into.

[originally from svn r7199]
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]
Correct embedding of Type 1 fonts in PDF. Error cases (e.g. invalid Type 1 2006-12-09T14:44:47+00:00 Ben Harris bjh21@bjh21.me.uk 2006-12-09T14:44:47+00:00 76b522bc5aac82f7d1c0e3433f1620a7a192bdad fonts) may not be well handled, and may emit invalid PDF. [originally from svn r6974] 
fonts) may not be well handled, and may emit invalid PDF.

[originally from svn r6974]
Fairly ropey font-embedding support. In particular, the PDF output is 2006-05-14T13:42:48+00:00 Ben Harris bjh21@bjh21.me.uk 2006-05-14T13:42:48+00:00 e06921ba9541759101336126a6af96ab66b9ee2d 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] 
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]