halibut/in_sfnt.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]
Turn the numeric parameter to err_sfntbadglyph from wchar_t to 2008-07-09T17:06:29+00:00 Simon Tatham anakin@pobox.com 2008-07-09T17:06:29+00:00 c35b288fccdbd17dd88f57c665d0b71739e8fc6c unsigned int, after a correspondent mentioned that DJGPP produces a very scary warning about integer promotion making use of the former in va_arg non-portable. Whether or not that's standards-justifiable, it's certainly the case that we were casting _to_ wchar_t from unsigned int in all cases of this error actually being used, so the simplest thing is just to transfer the number through va_arg as unsigned. [originally from svn r8112] 
unsigned int, after a correspondent mentioned that DJGPP produces a
very scary warning about integer promotion making use of the former
in va_arg non-portable. Whether or not that's standards-justifiable,
it's certainly the case that we were casting _to_ wchar_t from
unsigned int in all cases of this error actually being used, so the
simplest thing is just to transfer the number through va_arg as
unsigned.

[originally from svn r8112]
Cope with TrueType fonts with slightly broken cmaps, just ignoring code points 2007-12-02T18:38:31+00:00 Ben Harris bjh21@bjh21.me.uk 2007-12-02T18:38:31+00:00 5527360cf7e5b68a1954874c82128690ed7df488 that can't be resolved (apart from warning about it). [originally from svn r7800] 
that can't be resolved (apart from warning about it).

[originally from svn r7800]
Recognise a couple more types of Unicode 'cmap'. Also fail if a format 4 2007-12-02T00:01:30+00:00 Ben Harris bjh21@bjh21.me.uk 2007-12-02T00:01:30+00:00 b524d1b0431294e2943dc4cb35e9a5892b600a55 'cmap' refers to a character off the end of the glyphIndexArray. [originally from svn r7798] 
'cmap' refers to a character off the end of the glyphIndexArray.

[originally from svn r7798]
Cope with TrueType fonts that have duplicate glyph names by renaming glyphs 2007-02-13T00:12:16+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-13T00:12:16+00:00 7daf0d6079b52255d280841aa2906bb90abe3878 as necessary. The algorithm for ensuring that the new name is unused is partly Gareth's fault. [originally from svn r7277] 
as necessary.  The algorithm for ensuring that the new name is unused is
partly Gareth's fault.

[originally from svn r7277]
Cope with TrueType fonts without a 'post' table or with a format 3 'post' 2007-02-12T22:21:03+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-12T22:21:03+00:00 f42514d9eafc14726d17d47aff575f0a4a8e7aec table (which doesn't specify glyph names), constructing an arbitrary list of glyph names for ourselves. [originally from svn r7276] 
table (which doesn't specify glyph names), constructing an arbitrary list
of glyph names for ourselves.

[originally from svn r7276]
Presumed typo preventing compilation in r7269. 2007-02-11T17:30:49+00:00 Jacob Nevins jacobn@chiark.greenend.org.uk 2007-02-11T17:30:49+00:00 3cf31c6f5103cc936eb43a2a8bc6a7bb8d64f3e6 [originally from svn r7270] [r7269 == 6c660b39aeae18c4652a48318bff3373bb535d92] 
[originally from svn r7270]
[r7269 == 6c660b39aeae18c4652a48318bff3373bb535d92]
Improved error handling in sfnt support. No more calls to abort()! 2007-02-11T15:19:10+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-11T15:19:10+00:00 6c660b39aeae18c4652a48318bff3373bb535d92 [originally from svn r7269] 
[originally from svn r7269]
Add support for extracting kerning tables from 'kern' tables. Only format 0 2007-02-10T22:34:44+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-10T22:34:44+00:00 6e50bd3a744e0f1ca596636aa0c096de18ffc355 (simple pair kerning) is supported, but with both Apple- and Microsoft-format headers. Also reference Microsoft's TrueType specification in comments, since I've used that to write some of this code. [originally from svn r7268] 
(simple pair kerning) is supported, but with both Apple- and Microsoft-format
headers.

Also reference Microsoft's TrueType specification in comments, since I've used
that to write some of this code.

[originally from svn r7268]
Now that glyph indices are exposed to bk_pdf.c, move CMap generation there, 2007-02-10T13:35:52+00:00 Ben Harris bjh21@bjh21.me.uk 2007-02-10T13:35:52+00:00 f4b2ef94c1200ec17dad6a4502308f54371c9694 since that seems closer to being where it belongs. [originally from svn r7262] 
since that seems closer to being where it belongs.

[originally from svn r7262]