halibut/input.c, branch master My halibut tree Add missing err_cantopen. 2014-12-16T20:43:36+00:00 Simon Tatham anakin@pobox.com 2014-12-16T20:43:36+00:00 0a72bbbdf4b9ff119587782009839440a4869dad As far as I can tell from the source control history, Halibut has _never_ actually printed an error message on failure to open one of its input files! The error message has existed all along, but was never actually invoked. Ahem. 
As far as I can tell from the source control history, Halibut has
_never_ actually printed an error message on failure to open one of
its input files! The error message has existed all along, but was
never actually invoked. Ahem.
Fix segfault when a source file doesn't exist. 2014-12-16T20:34:04+00:00 Simon Tatham anakin@pobox.com 2014-12-16T20:34:04+00:00 cbe54149d478a58c5e385d1dd7d76fe97b1f1015 There was a missing NULL check in the code that test-opens files in both binary and text mode (for font-handling purposes). 
There was a missing NULL check in the code that test-opens files in
both binary and text mode (for font-handling purposes).
Add \s for 'strong' text, i.e. bold rather than italics. I've missed 2013-03-10T16:58:01+00:00 Simon Tatham anakin@pobox.com 2013-03-10T16:58:01+00:00 dcf080aa0e011de37a154e9e8a97dd7546a4a1b1 this a couple of times in Halibut markup recently (in particular, it's handy to have a typographical distinction between 'this term is emphasised because it's new' and 'this term is emphasised because I want you to pay attention to it'), so here's an implementation, basically parallel to \e. One slight oddity is that strong text in headings will not be distinguished in some output formats, since they already use bolded text for their headings. [originally from svn r9772] 
this a couple of times in Halibut markup recently (in particular, it's
handy to have a typographical distinction between 'this term is
emphasised because it's new' and 'this term is emphasised because I
want you to pay attention to it'), so here's an implementation,
basically parallel to \e.

One slight oddity is that strong text in headings will not be
distinguished in some output formats, since they already use bolded
text for their headings.

[originally from svn r9772]
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 macro definitions to be terminated by tok_eof as well as 2012-02-24T18:43:54+00:00 Simon Tatham anakin@pobox.com 2012-02-24T18:43:54+00:00 d4c6dfa05ee447a31aaeece63f9b9f062d26e5a8 tok_eop, to prevent Halibut tight-looping when a definition is the last thing in a file. [originally from svn r9419] 
tok_eop, to prevent Halibut tight-looping when a definition is the
last thing in a file.

[originally from svn r9419]
A user recently reported that Halibut's font-file handling doesn't 2010-02-27T23:42:39+00:00 Simon Tatham anakin@pobox.com 2010-02-27T23:42:39+00:00 e28f65738fadfe12b945db1e82f5d2c1a3f14553 work on Windows, because input files are never opened in binary mode. Introduce a small piece of compensatory mechanism, which opens files initially in binary mode and then reopens them as text if they're determined not to match any binary file type. I hope. [originally from svn r8889] 
work on Windows, because input files are never opened in binary
mode. Introduce a small piece of compensatory mechanism, which opens
files initially in binary mode and then reopens them as text if
they're determined not to match any binary file type. I hope.

[originally from svn r8889]
Enable Halibut to read a .but file from standard input, by supplying 2009-10-24T09:08:26+00:00 Simon Tatham anakin@pobox.com 2009-10-24T09:08:26+00:00 ccb035ab284dcce968d948a5f04eef96c9cc541d the special filename '-'. [originally from svn r8728] 
the special filename '-'.

[originally from svn r8728]
Correct mishandling of paragraphs beginning with "\#{". 2008-11-21T19:25:26+00:00 Simon Tatham anakin@pobox.com 2008-11-21T19:25:26+00:00 56b96573956a4035b9db0d73a8a07f2ed1526004 (Embarrassingly, this was showing up in inputs/test.but itself.) [originally from svn r8312] 
(Embarrassingly, this was showing up in inputs/test.but itself.)

[originally from svn r8312]
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]