| Summary: | new driver for ghostscript | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Johannes Feigl <johannes.feigl> |
| Component: | Other Driver | Assignee: | Johannes Feigl <johannes.feigl> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | htl10 |
| Priority: | P4 | ||
| Version: | 8.56 | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi/patch_gs-gpl_glassjet?bug=404017;msg=5;att=1 | ||
| Customer: | Word Size: | --- | |
| Attachments: | patch for new driver | ||
|
Description
Johannes Feigl
2006-12-29 08:28:06 UTC
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. |