From: Sambhav D. <sam...@gm...> - 2020-09-07 19:41:11
|
On Sat, Sep 5, 2020 at 11:34 PM Robert Krawitz <rl...@al...> wrote: > We really should move this discussion to > gim...@li... (gimp-print was the > original name for the project, which started with Mike's print plugin for > GIMP and was later renamed > to Gutenprint with the 5.0 release). > Sure, We'll move the discussion there. How will you review the code If I simply push my changes there? There might be many changes need to be made. > For filling the driver data: > > Reference the stp_image_t structure defined in > include/gutenprint/image.h. You need to write the > appropriate functions here. You can see the CUPS driver implementation in > src/cups/rastertogutenprint.c. > > Most of these are likely to be pretty simple. The hard one, of course, is > Image_get_row(). This is > called by the core via stp_image_get_row(). This one's going to pull a > row of raster data off the > queue and stick it in the provided data buffer, up to the number of bytes > specified (so you don't > overflow the buffer) and returns a status (either OK or abort -- that's > how a print can be aborted). > Yes. I've made the get_row function. To clear this out, there's no need for dimensions variables like left, right, etc. in the cups_image_t structure now, right? Since it will all be handled by PAPPL and we just have to pass the data to gutenprint. The raster format is either 8 or 16 byte (native ordering) K, W (inverse > grayscale) RGB, CMY,CMYK, > or KCMY. There's also a "raw" format, which allows specifying arbitrary > channels (currently > supported only for Epson printers, don't worry about that for now). > > As for filling in settings, your application does that and does the > necessary stp_set_* functions to > set up all the options. > Do we have to call stp_print for gutenprint to start printing the job? And I was asking for the callback function which PAPPL calls to fill the driver data structure for PAPPL? -- Sambhav |