halibut/psdata.c, branch master My halibut tree Fill in the 'filetype' field for standard PS fonts. 2017-05-14T07:45:00+00:00 Simon Tatham anakin@pobox.com 2017-05-14T07:16:42+00:00 90b5c251fd86c444f54184d0d30e3d6462cbb7ae This was another valgrind-spotted uninitialised variable. And although you'd think the 'filetype' field is unimportant for fonts that aren't loaded from a file anyway, it is important, because bk_pdf.c emits different code for creating font subsets of Type 1 and TrueType fonts - i.e. it needs to know what type the font has _after_ it's loaded, not just how to load it. 
This was another valgrind-spotted uninitialised variable. And although
you'd think the 'filetype' field is unimportant for fonts that aren't
loaded from a file anyway, it is important, because bk_pdf.c emits
different code for creating font subsets of Type 1 and TrueType fonts
- i.e. it needs to know what type the font has _after_ it's loaded,
not just how to load it.
Tidy up the handling of non-standard glyphs by defining glyph_extern() 2007-02-04T14:16:26+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-04T14:16:26+00:00 89017ba7004b9cb9e944775232c5ab917b40f262 early and using it whenever we need the name of a non-standard glyph. [originally from svn r7216] 
early and using it whenever we need the name of a non-standard glyph.

[originally from svn r7216]
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]
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]
Generate ligature information from the standard AFM files rather than 2007-01-01T15:32:32+00:00 Ben Harris bjh21@bjh21.me.uk 2007-01-01T15:32:32+00:00 79884384cdb4a2d917f49cbd532f8f41988c0893 hard-coding it. No practical gain, since the hard-coded entries were correct, but aesthetically better. [originally from svn r7046] 
hard-coding it.  No practical gain, since the hard-coded entries were correct,
but aesthetically better.

[originally from svn r7046]
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]
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]
Initial support for adding fonts at run-time. Currently we only support 2006-05-13T13:56:05+00:00 Ben Harris bjh21@bjh21.me.uk 2006-05-13T13:56:05+00:00 c072eb7debe80aca352a5dc26bff08a6ecd8baff 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] 
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]