hi ghostscript team, this a not a bug report, it's a patch to have a new output-driver. i've written a new driver for a mashine we are using in our company, called "glassjet", is uses a special type of uncompressed tiff files. the output-driver is very simple. http://www.its-eng.com/printers_glassjet.asp here you can see some informations about the mashine if you wanna know about it. i want to make it free available for everybody. do you know to who i should send it that it will be added in the next version? (please make some cleanup) you can find the patch for version 8.54 here: http://bugs.debian.org/cgi-bin/bugreport.cgi/patch_gs-gpl_glassjet?bug=404017;msg=5;att=1 i've tested it and it works well. thanks regards, johannes
Created attachment 2666 [details] patch for new driver
Firstly, somebody else would say this: a modular design like ijs or opvp outside of ghostscript are preferred over compiled-in drivers. Please consider re-writing it as ijs/opvp and just release it on your own like hpijs/gutenprint etc. Secondly, on general technical grounds, the use of printf() and fwrite()... I have not seen any of current gs's compiled in driver writes to stdout directly. That aspect of the submitted patch is deeply wrong. As for the actual implementation... the hand-crafted hex-dump in glassjet_tiff_header() - the format the printer accepts looks like uncompressed bitmap at fixed resolution with a custom header which just happens to be mostly tiff-like. it may be possible to wrap ghostscript's pbm output with a shell/perl script or tuning tiffrle/tiffpack without the rle/pack part to achieve the same end. All in all, I think the patch cannot be accepted, if only just based on the printf()/fwrite() aspect alone. (I don't speak for the gs developers - consider this a 3rd party opinion).
hi, well it does not use printf(), it uses fprintf. so the output is not going to stdout, ist going to the output-stream "prn_stream". this means it could be stdout, a file, or e.g. a LPT device (what you want and telling GS to use). if you have a better idea instead of fprintf/fwrite please tell me. the file format is a typical (uncompressed) tifffile, but the problem is, that the header is fixed. the parameters must be in this order, otherwise the tifffile does not work with the mashine. i also thought about using order possibilities of creating such a file with ghostscript, but i think this is a fasted way. regards, johannes
I have an impression that gs has some macros to do with the output stream. I think the driver can be written as a perl-(or python or shell) wrapper/filter around the pbmraw device.
Please change this patch so that it adds into 'contrib' and contrib.mak as that is where we put this type of less popular devices.
hi ray, thanks for your (late) reply, i have to check again for the change for 'contrib' and contrib.mak. but anyway, the patch-like-working with fprintf etc is ok? regards, johannes
Quite a few out-in-the-wild patches floating around ESP GS have gone into the contrib directory in 8.60, so the climate has changed. OTOH, ijs, opvp, cups raster are ways of maintaining a driver outside the ghostscript tree.
Closing this since Hin-Tak's suggestions for distributing this independently of Ghostscript as a cups raster device, or an 'ijs' driver, both of which can be distributed independently and do not require re-compilation of Ghostscript make sense. A third simple approach is to write the 'custom' output format by taking something simple such as ppm or pbm in and then distributing a 'filter' program that converts the file from Ghostscript makes sense.