GNOME Bugzilla – Bug 446894
Clean up printing in Evolution's Mailer
Last modified: 2008-06-30 16:05:50 UTC
Following up on bug #426816, this bug tracks improvements to printing from Evolution's Mailer component. The goals of this bug are as follows: - Make GtkHtml's printing API more GtkPrint-friendly. - Fix pagination and rendering issues when printing emails. - Fix all confirmed mailer bugs with the keyword "printing". My proposed changes to the GtkHtml API are as follows: - Deprecate the existing printing API: gtk_html_print_page() gtk_html_print_page_with_header_footer() gtk_html_print_page_get_pages_num() - Introduce a new function that takes a GtkPrintOperation: GtkPrintOperationResult gtk_html_print_operation_run (GtkHtml *html, GtkPrintOperation *operation, GtkPrintOperationAction action, GtkWindow *parent, GtkHTMLPrintCalcHeight calc_header, GtkHTMLPrintCalcHeight calc_footer, GtkHTMLPrintDrawFunc draw_header, GtkHTMLPrintDrawFunc draw_footer, gpointer user_data, GError **error) - There are four callbacks in this new function. calc_header and calc_footer are called from the internal signal handler for the "begin-print" GtkPrintOperation signal. These callbacks, if provided, are responsible for calculating the height (in Pango units) of the page header and footer respectively. The results of these callbacks are used to paginate the document. draw_header and draw_footer are called from the internal signal handler for the "draw-page" GtkPrintOperation signal. These callbacks are responsible for drawing the header and footer for the given page number to a Cairo context. The function signatures for these callbacks are as follows: typedef gint (*GtkHTMLPrintCalcHeight) (GtkHTML *html, GtkPrintOperation *operation, GtkPrintContext *context, gpointer user_data) typedef void (*GtkHTMLPrintDrawFunc) (GtkHTML *html, GtkPrintOperation *operation, GtkPrintContext *context, gint page_nr, PangoRectangle *rec, gpointer user_data) - We also need to allow applications to set the default printing font in GtkHTML, which is currently hardcoded to "Sans 8". I haven't finished this part yet.
Created attachment 89838 [details] [review] Patch for GtkHTML (first draft)
Created attachment 89839 [details] [review] Patch for Evolution This patch makes Evolution use the new GtkHTML printing API.
Created attachment 89864 [details] [review] Revised patch for Evolution Correction to the calculation of footer_height. I still had it being calculated in points rather than Pango units.
Created attachment 90249 [details] [review] Revised patch for GtkHTML I was actually trying to use this patch to print a multi-page reservation confirmation from Hertz and GtkHTML kept crashing in htmlengine.c:thaw_idle(). When I examined htmlengine.c I found that in several places the logic is incorrectly assuming that the HtmlEngine's painter is a HtmlGdkPainter (a subclass of HtmlPainter), whereas in this case the painter is a HtmlPrinter (another subclass of HtmlPainter). The most egregious examples of this are in html_engine_realize(), html_engine_unrealize(), and of course thaw_idle(). This patch adds a lame workaround to the problem by checking the type of the painter before calling a HtmlGdkPainter-specific operation. A better solution might be to add new methods to the HtmlPainter class (realize(), unrealize(), etc) and have subclasses override them appropriately. In any case, I was finally able to print my Hertz reservation.
p.s. I don't understand how the current code manages to not crash. It seems like it should be susceptible to the same flawed logic in htmlengine.c. A fluke, perhaps?
Created attachment 90380 [details] [review] Revised patch for Evolution Although not strictly mailer related, this revision adds a Page Setup dialog to Evolution, accessible from any component via a new File menu item. The Page Setup dialog is used to customize the printer page size and orientation. These settings are retained across sessions by storing them in GConf along with the other print settings (GConf key: /apps/evolution/shell/printing).
Srini, ping: any chance of getting this into 2.11.5? It seems to be working fine as far as I can tell, but could use more widespread testing if it's going to make 2.12.
I would really appreciate it, since Evo printing is right now hopelessly broken if one uses any page size different from A4.
confusing, because a "page setup" tab also exists when choosing the "print" menu item. so now we have two "page setup" thingies with totally different stuff to configure? hum...
(In reply to comment #9) That's largely a GtkPrint issue. Epiphany and Evince, for example, have a similar problem. Although they both label their menu item "Print Setup" instead of "Page Setup", the resulting dialog is still titled "Page Setup" (by GTK+). They also use the standard GTK+ print dialog, which includes a "Page Setup" tab. I can certainly rename the menu item to "Print Setup" to be consistent with Epiphany and Evince, if you think that would help. Most other print-capable GNOME applications I've looked at use non-standard and highly customized print and page setup dialogs, which I'd rather avoid.
Matthew, very much in my list for 2.11.5. **SNIP** from the mail sent to the maintainers (including you) for the todos for 2.11.5 http://bugzilla.gnome.org/show_bug.cgi?id=446894 (Srini/Akhil: Akhil for testing)
Matthew, I tried few scenarios with this patch.I have not completed my full testing yet.But i have observed few things which i am writing down 1) Print preview button is not displaying any thing. I tried with Menu option and in print window also. In print window as soon as i click on print preview button , instead of opening print preview window,it closes existing print window also. 2) In print window 'current page' is not enabled 3) Why it is saving previous settings ? Is it written like that ? Because if i give 'page range', next time when i will select 'all pages' option,it will display range also. Same scenario with 'job tab' in print window also.In print document option if i select 'now' after 'at',then also it doesn't clear the data filled in 'at' 4) If i click on 'my print' then 'print' button will be disabled and then it won't be enable until i select actual printer once. 5) When i give print command to a mail with images , it hangs for approx 10 seconds and in status bar, it will display 'formatting message' in status bar. 6) Once Evolution hanged when i had given print command. I am attaching traces. Hope this helps !
Created attachment 91180 [details] GdbTraces when evolution hanged
Akhil, the trace could be due to the screwed up build environment in my machine.
Hi Ankil, thanks for testing this! I'll comment on your observations point for point: 1) Print Preview should spawn evince in preview mode. It worked fine for me the last time I tried, so I guess make sure you have evince installed. Meanwhile I'll double check it against the latest Subversion source. Maybe try running Evolution from a terminal and watch for any helpful messages or clues printed to the terminal when you try to Print Preview. When the Print Preview button is clicked from the Print dialog, GTK+ spawns evince and then closes the dialog. That's standard behavior. 2) I'm not sure it makes sense to enable that. Evolution doesn't break information into "pages" like a word processor or PDF viewer does. 3) Yes, it indiscriminately saves all printer settings to GConf (see /apps/evolution/shell/printing). 4) I'm not sure I understand what you're describing but it sounds like standard GtkPrint behavior. The print dialog is a standard GTK+ widget [1] and Evolution doesn't have much control over its behavior. We just run dialog and wait for a response, much like the file chooser dialog. 5) Sounds like GtkHTML is busy doing _something_. For the purpose of printing, the new API just hands GtkHTML a Cairo context and says "here, draw on this." I didn't change the drawing logic. 6) It looks like perhaps GnomeVFS got stuck looking up a MIME type. I don't see anything in the backtrace related to the printing changes. [1] http://developer.gnome.org/doc/API/2.0/gtk/GtkPrintUnixDialog.html
Oh and sorry for butchering your name, Akhil. :)
I tried to print HTML mail with inline images.But it is not printing. I tried same scenario with head also. It is not working there also. What ever scenarios/test cases i tried during testing,i have uploaded mbox file on below URL http://gnomebangalore.org/~sragavan/print.mbox You can also test personally with this file.It covers almost all possible scenarios. One more thing regarding comment#12 point 3 It will be great if we can have revert/set to default option, so that i can go back to my previous settings. Other wise it is very difficult and annoying to go to each option and change it manually to previous/default setting. Other things are working fine. Great !!
Matthew, it seems like a issue with OpenSUSE and the Printer hardware that we use here. It will be great if you can use Akhil's test case and test your patch. We tested the other things like Range etc, which rocked!. Awesome work. We observed some crashes too, but the traces were useless. I want to push this to 2.11.5. Im marking the status as commit now. Please test with images in akhil's mbox file and commit after that :)
i also have not been able to print images in html emails for some years. bug 355002 could also be related...
Commited both patches: gtkhtml - revision 8489 evolution - revision 33762 Noticed a couple bugs as I was going through the mbox file: 1) Trying to print a meeting invitation locked up Evolution and started some kind of heavy duty I/O task, but I think it's a known bug. 2) The "Page n of n" footer seems to be omitted for large emails but is present for small emails. Don't yet know where the threshold lies or why that's happening. I'll leave this bug open until the end of the 2.11 development cycle. I imagine further revisions will be necessary to fix bugs or incorporate user feedback.
To fix the hard coded font, shouldn't the widget font be used. This is the expected behaviour from the user prospective. Also the htmlfontmanager.c defaults to the widget font, see htmlpainter.c : html_painter_alloc_font() "desc = pango_font_description_copy (gtk_widget_get_style (painter->widget)->font_desc);" htmlprinter.c : html_printer_new() change desc = pango_font_description_from_string ("sans 8");/* FIXME font hardcoded*/ to desc = pango_font_description_copy (gtk_widget_get_style (widget)->font_desc); This is provided that setting a font here does anything. The old gnomeprint API required setting the default font for every new page. But it didn't work.
When I apply the gtkhtml patch, Gnucash reports are one page long and seem to rendered one page over another with only one physical page in the final output.
Created attachment 94078 [details] [review] Patch to fix regression in old printing API This patch should fix the regression in the old printing API that Bernard reported seeing with GnuCash. I haven't tested it with GnuCash explicitly, but I was able to reproduce the same problem by running Evolution 2.10 against GtkHTML 3.15.90 (2.10 uses the old printing API). This patch also fixes the extra-blank-page-at-the-end bug that we were seeing prior to the new printing API.
Matthew, looks fine to me. I haven't tried it though.
Committed patch in comment #23, revision 8540.
*** Bug 470819 has been marked as a duplicate of this bug. ***
Created attachment 113501 [details] [review] Fix font kerning Managed to fix the font kerning problem in printed emails. This also fixes the problem where the printed font doesn't match the user's preferred font. Would be nice to get this into 2.22.3.
*** Bug 271715 has been marked as a duplicate of this bug. ***
*** Bug 302904 has been marked as a duplicate of this bug. ***
I may have been a bit hasty. With the patch in comment #27 applied, my Print Previews are shown perfectly but the text in an actual printout gets slightly cut off along all four edges. Can someone confirm this so I know it's not just my own printer acting up? There is absolutely no difference in the rendering code for a print preview versus an actual printout, so I can't yet explain why this is happening.
(In reply to comment #30) > I may have been a bit hasty. With the patch in comment #27 applied, my Print > Previews are shown perfectly but the text in an actual printout gets slightly > cut off along all four edges. Can someone confirm this so I know it's not just > my own printer acting up? > > There is absolutely no difference in the rendering code for a print preview > versus an actual printout, so I can't yet explain why this is happening. > I applied your patch to my Fedora 8 (gtkthml3-3.16.3-1.1.fc8) system. My reports with GnuCash look much better now. I don't know that I'd say the font kerning is 'superb', but it's much better than before. Any remaining issues are probably related to the font itself. I'm also not seeing any reports that are cut off on any edge.
Matt, looks fine to me, pro'lly you can commit to trunk only, if you aren't sure.
Couldn't reproduce the clipping issue that I was seeing at home with the printers at work, so committing this to GtkHtml trunk (revision 8882). I think we can finally close this bug.