Re: [Gimp-print-devel] Introduction

[Robert K. <rl...@al...>]

On 5/22/22 08:52, Sahil Kumar wrote:
> Hey community, I am Sahil a sophomore engineering student. My proposal for "*Make native Printer
> Application for Gutenprint*" has been accepted as a part of GSoC 2022. 
> 
> Can somebody help me get started with Gutenprint as I am new to it? What is expected in a Printer
> Application? 

Hi,

I assume Till has discussed with you in general what a printer is, so I won't go into that.

Gutenprint is a suite of printer drivers for Linux, MacOS, and other POSIX operating systems.  It's
divided into a number of components:

* The core library, which provides the Gutenprint API (which only has C bindings) that higher level
client applications use to provide printing services (in src/main).  The Gutenprint API includes
functionality for things like printing raster data (on a page basis), printer and option discovery,
and option setting.  Your native printer application should interface only with the core API,
defined in <include/gutenprint>.  The library provides other downward-facing services (see next
paragraph).  *Everything in the API is prefixed with "stp_" and you should not use anything prefixed
with "stpi", as these are internal functions*.

* Drivers for families of printers (e. g. Epson inkjets, Canon inkjets, PCL printers, dye
sublimation printers).  These family drivers provide information to Gutenprint about what printers
they support and their capabilities via an internal API (in <include/gutenprint-internal>, which you
should not use), in addition to sending printer-specific commands, and in some cases
printer-specific communication protocols).  The Epson inkjet driver uses XML data internally to
describe printers, so it doesn't require changes to .c files in most cases to add new printers.  The
other family drivers hard code much of the information, although the list of supported printers is
always in XML.

* A CUPS driver based on the CUPS 1 standard, using PPD files for applications to discover and set
printer options (in src/cups).  Included with this is a PPD file generator using the Gutenprint API
to discover options; there's also a utility to update PPD files, as PPD files are version locked to
the micro version of Gutenprint that they were generated for (this enables us to add new
capabilities to printers).  Both the CUPS driver and the PPD file generator are Gutenprint API
clients.  *This is the piece that the printer application will replace*.

* A GIMP2 plugin.  This is actually divided into two parts, a generic (or at least not
GIMP-specific) UI library (src/gutenprintui2) and a GIMP-specific plugin (src/gimp2).  Both of these
are interactive; libgutenprintui2 provides the actual UI, while src/gimp2 is the GIMP glue code.

The capabilities of printers vary substantially, and I'm a strong believer in exposing as much
functionality as possible to end users to enable maximum control, so the goal here is to create a
Printer Application that exposes the full capabilities of Gutenprint without the use of PPD files in
the legacy CUPS driver.  The idea is certainly not to blitz an end user with a huge list of options,
so options are divided into two classes, one for printer functionality and one for color adjustment,
and several different levels, from basic through more levels of advanced options.  That can suggest
to applications how to organize what they present to end users.  It's possible using the more
advanced options to cause problems (e. g. by using excessive amounts of ink for the media used), but
some of these options are needed for use cases such as T-shirt printing.  Printing T-shirts, for
example, requires use of enormous amounts of ink, but if someone tries to apply that much ink to
paper, it will puddle and likely make a real mess inside the printer.  Options like that are always
in one of the more advanced levels.

A problem with the PPD file approach is that they're static; they cannot easily represent
dependencies between options, so we currently have to be very permissive about what combinations of
options we accept.  Interactive clients, such as the GIMP plugin and the printer application that
you'll be writing, can manage dependencies, so we can do things like hiding color options for
grayscale printing.  Clients don't need to know anything about those options per se; the core API
presents the options that are compatible with other options that are set.

My suggestion would be to start learning how Printer Applications work, and to use libgutenprintui2
to see how an interactive client interacts with libgutenprint.

I'm the project lead for Gutenprint.  Unfortunately, due to personal circumstances my time and
energy will be limited this summer, so I will not be your main mentor.  Solomon Peachy, a very
experienced developer who has been with Gutenprint for many years, will be your direct mentor.  I
will answer questions as I can, but I may not be very responsive much of the time.