halibut/in_afm.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]
Remove a bunch of unused variables spotted by Ubuntu 12.04's gcc. 2012-05-03T17:43:21+00:00 Simon Tatham anakin@pobox.com 2012-05-03T17:43:21+00:00 689093cc870e60ab82a176c33613fa0aeaa0bf69 [originally from svn r9478] 
[originally from svn r9478]
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]
Support for getting ligature information from AFM files, which was the 2007-01-07T00:15:52+00:00 Ben Harris bjh21@bjh21.me.uk 2007-01-07T00:15:52+00:00 669b28cebeb55e7a6a5c3edce969ba478672efcc whole point of the glyph renumbering. [originally from svn r7066] 
whole point of the glyph renumbering.

[originally from svn r7066]
Make ps_glyph_to_unicode() take a glyph index instead of a glyph name. 2007-01-06T17:47:34+00:00 Ben Harris bjh21@bjh21.me.uk 2007-01-06T17:47:34+00:00 fb816f82ea8a90a1e92557dcc699cbcfe53f236c [originally from svn r7062] 
[originally from svn r7062]
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]
Initial ligature support. This adds support for emitting ligatures, and adds 2006-12-31T21:38:46+00:00 Ben Harris bjh21@bjh21.me.uk 2006-12-31T21:38:46+00:00 b83d28dfd3434a31fd42f0596ab299a2626230d6 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] 
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]
Remember to initialise the bmp array for AFM fonts, or Unicode fallbacks 2006-12-09T20:12:30+00:00 Ben Harris bjh21@bjh21.me.uk 2006-12-09T20:12:30+00:00 9d620d33d1869108c2bb67eaca8d8441951ca432 won't work properly. [originally from svn r6982] 
won't work properly.

[originally from svn r6982]
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]
Generate a more-or-less valid /FontDescriptor dictionary for non-standard 2006-05-13T15:52:03+00:00 Ben Harris bjh21@bjh21.me.uk 2006-05-13T15:52:03+00:00 9f368a32d754b2827a38f51aa6191aa625ce6a10 fonts in PDF output. [originally from svn r6684] 
fonts in PDF output.

[originally from svn r6684]