This bug tracks the first phase of an effort to clean up printing in Evolution.

The goals of the first phase are:

   - Eliminate Evolution's dependency on libgnomeprint[ui].

   - Make the printing code portable again by avoiding GtkPrintUnixDialog.

   - Refactor the printing infrastructure to better utilize the GtkPrint API.


This first phase does NOT focus on rendering issues in the printed output, though it does fix some.  In particular, Evolution now honors the user's choice of paper size and print margins.  But pagination in emails and contact lists is still broken, and printed calendars still have several text layout issues.  Also, printed tabular views, such as the calendar's "list view" or the contact "phone list" view, are still very rudimentary and not very useful.  These issues will be dealt with in the second phase.


Some random notes:

  - The e-print API now consists of a single function:

        GtkPrintOperation * e_print_operation_new (void)

    The returned GtkPrintOperation is already configured with the custom
    print settings from GConf.  In addition, it will automatically store
    the print settings after the printing operation has completed.  It
    also handles displaying an error dialog to the user when a printing
    error has occurred.  All the caller has to do is connect to the
    appropriate "draw" signals and run the operation.

  - The e-contact-print API has also been reduced to a single function:

        void e_contact_print (EBook *book,
                              EBookQuery *query,
                              GList *contact_list,
                              GtkPrintOperationAction action)

    Also, this module uses an "EFlag" for thread synchronization.
    EFlag is a proposed enhancement to libedataserver (see bug #415891)
    that simplifies thread synchronization and largely replaces the role
    of EMsgPort in Evolution (see bug #362638).

  - The e-contact-print-envelope module is unused and appears to be
    unfinished.  It was developed prior to Evolution 2.0 and hasn't seen
    much maintenance since.  I have disabled the module but preserved most
    of the GnomePrint-based rendering code for future reference.

  - calendar/gui/print.c has a lot of modifications to the rendering code
    but it's all just refactoring with no alterations to the printed output.
    It was while working on this module that I decided to break the effort
    into two phases to keep the infrastructure work and the end-user-visible
    work separated (and to avoid endless nitpicking).  So much of those
    changes are preliminary phase two work.