GNOME Bugzilla – Bug 522708
RFE: Support page headers and footers in GtkPrint
Last modified: 2018-02-10 03:44:15 UTC
Applications often use page headers and footers when printing to show things like page numbers, document title, etc. It would be nice if GtkPrint made this a little easier. When I helped port libgtkhtml from GnomePrint to GtkPrint, the printing API we were left with was kind of clunky and awkward because the library allows applications to draw a custom header and footer on each page, while the library itself draws the main content. With WebKit/GTK+ strugging with the same issue in their printing API, it got me thinking about the problem again. Here's a proposal for extending GtkPrintOperation to make fixed-height page headers and footers easier. I think it should be backward-compatible. Add the following functions to GtkPrintOperation: gdouble gtk_print_operation_get_header_height (GtkPrintOperation *op, GtkUnit unit); void gtk_print_operation_set_header_height (GtkPrintOperation *op, gdouble height, GtkUnit unit); gdouble gtk_print_operation_get_footer_height (GtkPrintOperation *op, GtkUnit unit); void gtk_print_operation_set_footer_height (GtkPrintOperation *op, gdouble height, GtkUnit unit); The header and footer heights would default to 0.0. Then add "draw-header" and "draw-footer" signals to GtkPrintOperation. These have the same signature as the "draw-page" signal, but each get their own appropriately sized GtkPrintContext. gtk_print_context_get_height() would return the header or footer height instead of the main drawing area height. The new signals would only be emitted if the corresponding header/footer heights are greater than zero, and the height of the main drawing area would be decreased to accommodate them. The signals would be emitted top-to-bottom: "draw-header" (only if header-height > 0) "draw-page" "draw-footer" (only if footer-height > 0) Then the three contexts would be assembled and the page printed. I'm not very familiar with the internals of GtkPrint yet, so I haven't attempted an implementation. But does this proposal sound feasible?
Sounds feasible.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.