Bug 1099143 and more occurences of the same set vs. get mistakes.

[wxWidgets.git] / docs / latex / wx / tprint.tex

\section{Printing overview}\label{printingoverview}

Classes: \helpref{wxPrintout}{wxprintout}, 
\helpref{wxPrinter}{wxprinter}, 
\helpref{wxPrintPreview}{wxprintpreview}, 
\helpref{wxPrinterDC}{wxprinterdc}, 
\helpref{wxPrintDialog}{wxprintdialog}, 
\helpref{wxPrintData}{wxprintdata}, 
\helpref{wxPrintDialogData}{wxprintdialogdata}, 
\helpref{wxPageSetupDialog}{wxpagesetupdialog}, 
\helpref{wxPageSetupDialogData}{wxpagesetupdialogdata}

The printing framework relies on the application to provide classes
whose member functions can respond to particular requests, such
as `print this page' or `does this page exist in the document?'.
This method allows wxWidgets to take over the housekeeping duties of
turning preview pages, calling the print dialog box, creating
the printer device context, and so on: the application can concentrate
on the rendering of the information onto a device context.

The \helpref{document/view framework}{docviewoverview} creates a default
wxPrintout object for every view, calling wxView::OnDraw to achieve a
prepackaged print/preview facility.

A document's printing ability is represented in an application by a
derived wxPrintout class. This class prints a page on request, and can
be passed to the Print function of a wxPrinter object to actually print
the document, or can be passed to a wxPrintPreview object to initiate
previewing. The following code (from the printing sample) shows how easy
it is to initiate printing, previewing and the print setup dialog, once the wxPrintout
functionality has been defined. Notice the use of MyPrintout for
both printing and previewing. All the preview user interface functionality
is taken care of by wxWidgets. For details on how MyPrintout is defined,
please look at the printout sample code.

\begin{verbatim}
    case WXPRINT_PRINT:
    {
      wxPrinter printer;
      MyPrintout printout("My printout");
      printer.Print(this, &printout, true);
      break;
    }
    case WXPRINT_PREVIEW:
    {
      // Pass two printout objects: for preview, and possible printing.
      wxPrintPreview *preview = new wxPrintPreview(new MyPrintout, new MyPrintout);
      wxPreviewFrame *frame = new wxPreviewFrame(preview, this, "Demo Print Preview", wxPoint(100, 100), wxSize(600, 650));
      frame->Centre(wxBOTH);
      frame->Initialize();
      frame->Show(true);
      break;
    }
\end{verbatim}

\section{Printing under Unix (GTK+)}\label{unixprinting}

Printing under Unix has always been a cause of problems as Unix
does not provide a standard way to display text and graphics
on screen and print it to a printer using the same application
programming interface - instead, displaying on screen is done
via the X11 library while printing has to be done with using
PostScript commands. This was particularly difficult to handle
for the case of fonts with the result that only a selected
number of application could offer WYSIWYG under Unix. Equally,
wxWidgets offered its own printing implementation using PostScript
which never really matched the screen display.

Starting with version 2.8.X, the GNOME project provides printing
support through the libgnomeprint and libgnomeprintui libraries
by which especially the font problem is mostly solved. Beginning
with version 2.5.4, the GTK+ port of wxWidgets can make use of
these libraries if wxWidgets is configured accordingly and if the
libraries are present. You need to configure wxWidgets with the
{\it configure --with-gnomeprint} switch and you application will
then search for the GNOME print libraries at runtime. If they
are found, printing will be done through these, otherwise the
application will fall back to the old PostScript printing code.
Note that the application will not require the GNOME print libraries
to be installed in order to run (there will be no dependency on
these libraries).

It is expected that the printing code that is currently implemented
in the GNOME print libraries will be moved into GTK+ later.