As the device API passes a FILE * into the device methods, a device can write to stdout/stderr via the FILE *, but that bypasses any stdio handler callbacks set via the GS API ( gsapi_set_stdio() ). It would be preferable when a device is outputting to stdout/stderr (for example, if -sOutputFile=- is given on the command line), that the output is directed via the appropriate gsapi_set_stdio() set handler. My suggestion is to implement a gp_fprintf() (or gs_fprintf()) function: int gp_fprintf(const gs_memory_t *, FILE *, const char *fmt, ...); That would check whether the input FILE * was actually stdout or stderr, and if so would call the appropriate internal function to direct output to that, otherwise it would fall through to using fprintf() directly. This came up as the inkcov device output could not be captured by the gsapi_set_stdio() set handlers - inkcov now has a solutions for that, but this enhancement is for a general solution that can be applied to other devices.
The documentation "API.htm" should contain a hint, that the callback handlers set with gsapi_set_stdio() are not obeyed if a device (-sDEVICE=..) is given. Would have saved me, and probably other users, some time.
(In reply to Thomas Loimer from comment #1) > The documentation "API.htm" should contain a hint, that the callback > handlers set with gsapi_set_stdio() are not obeyed if a device (-sDEVICE=..) > is given. > > Would have saved me, and probably other users, some time. I've added a note to that effect: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=6a46e31d5005
The hold-up implementing a solution to this is down to finding a nice way to preserve the current bahaviour, whilst also allowing this to work. The problem is, the current behaviour is intended to allow (by implementing custom stdio callbacks) device output to be streamed to stdout, without the risk of backchannel warnings or error messages corrupting the device output data. I would prefer this not to involve yet another command line option (we already have *way* too many!).