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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice