[cups-devel] Calling a CUPS filter under different names so that it behaves differently
msweet at apple.com
Wed Jul 6 04:35:13 PDT 2016
The simplest solution is to provide separate programs that perform only those functions required rather than gating things based on the program name. Use shared source files for any common functionality (the built-in CUPS filters do this).
The next simplest solution is to have a common source file that has a "filter_main" function accepting the program name in addition to argc and argv, e.g.:
int filter_main(const char *filter, int argc, char *argv)
... do stuff ...
and then have separate source files that provide a main() function calling into it. You still end up with separate programs but if they share significant amounts of code it might be feasible.
> On Jun 27, 2016, at 4:41 PM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
> cups-filters contains a filter named gstoraster, which is a CUPS filter written in C which calls Ghostscript to convert PDF or PostScript input into CUPS or PWG Raster output.
> There are also two other filters, pstopdf and gstopxl which are shell scripts. Problem of these filters is that they directly read the print queues PPD file (/etc/cups/ppd/*.ppd) and this does not work any more due to file permission changes.
> Therefore I want to replace these two filters by equivalent filters written in C. And as these filters call Ghostscript like gstoraster does they would get very similar to gstoraster. Now I want to avoid duplicate code and therefore I modify gstoraster to be able to also output PDF or PCL-XL, depending on the name of the executable (gstopdf, gstopxl) and add gstopdf and gstopxl links to gstoraster in /usr/lib/cups/filter/.
> First, I have used symbolic links and tried to read argv, but this does not work as CUPS sends the print queue name to its filters using argv.
> So I tried an alternative approach, reading the /proc/self/exe symlink which points to the executable file. This has two problems:
> - /proc/self/exe exists only under Linux, on other systems it has another name or there is perhaps even no /proc file system
> - The alternative filter names in /usr/lib/cups/filter/ must be hard links, if they are symbolic links, /proc/self/exe only points to the name of the actual executable file, not of the symbolic link through which it was called.
> Any suggestions to how to implement this the best way?
> cups-devel mailing list
> cups-devel at cups.org
Michael Sweet, Senior Printing System Engineer
More information about the cups