Google Summer of Code 2017 - Some help needed

[Caolán McNamara]

On Thu, 2017-04-27 at 18:45 -0300, Till Kamppeter wrote:
> 
> In the Google Summer of Code 2017 a big project of OpenPrinting will
> be work on the print dialog. What we especially want to do is:
> 
> - Common backends to all print dialogs (GTK, Qt, LibreOffice, ...):
>     - Backend for local CUPS queues
>     - Backend for IPP network printers
>     - Backend for Google Cloud Print printers
>     - In the future: Backends for new, upcoming print technologies
> (for example a cloud printing service based on PWG standards.

The main question for me is what format/mechanism is provided by the
user of the backend as the print transport format/mechanism, e.g. if
it's simply (like cups) "give me the pdf to print" then it's relatively
easy. If it's (like GtkPrintOperation) "here's a cairo context, render
onto it what you want printed", then its not easy.

> As talked about on the IRC LO allows also switching to the GTK
> dialog and there will also be a new GTK dialog which will get
> launched in around two years.

So IIRC we did a review in 2009 of the gtk print dialog, and then
another review in 2012 and its now 2017 and apparently there will be a
new dialog in around two years :-)

> The backend idea comes already from the new GTK dialog and we want
> to get it to life as soon as possible.
> 
> It is told that it is difficult to do Spreadsheet printing with the 
> usual print dialogs and therefore it could be better for LO to stay
> with its own dialog.

Well, I'd *like* to use the gtk print dialog personally. The
reoccurring  problem is typically spreadsheet printing. You can see in
our own dialog in calc that when printing the "range" is "range and
sheets" with selection of what sheets to print and the range from those
sheets. The gtk print dialog just offers what pages to print. Gnumeric
works around this in the standard gtk print dialog with putting a
custom "gnumeric print range tab" which is distant from the page range
to print. It's not a good fit.

Multiple pages per sheet is another problem, the gtk one is more
limited than the offerings of the LibreOffice one.

Providing a preview which updates as you change the selection or
options is another problem.

What it means to change the paper size/orientation in the printer
dialog when the application supports multiple paper sizes and
orientation in the document is an open question I suppose.

> So what I would like to know is the following:
> 
> - Would it be a good idea to modify the inner workings (not the GUI)
> of the LibreOffice print dialog to talk to the printing 
> system(s)/printer(s) through a modular backend so that easily new
> print technologies can be added or changes for the existing ones
> being supplied?

Assuming that we can just supply a final pdf to the print backend then
this sounds sensible to me. Relatively not difficult to add new
parallel support for retrieving printer lists and printer info and
sending print jobs alongside our existing ones.

> - Or is it no problem for Spreadsheet printing to use the current
> and/or the future GTK print dialog so that it is a better approach to
> let LO default to the GTK dialog?

If anyone has good ideas about how to make the existing gtk dialog not
a miserable experience for spreadsheet printing that'd be cool.
Otherwise I guess defaulting to the current GTK dialog is probably not
going to fly. Maybe the next one will solve all these problems.