Re: gtk_print

[Chris Vine <chris cvine freeserve co uk>]

On Fri, 22 Aug 2008 13:40:20 +0200 (CEST)
"Richard Boaz" <riboaz xs4all nl> wrote:
[snip] 
> The reason I have a PS file in the first place is historical.  Back
> when I originally wrote my plotting program, it was v2.4 of GTK+,
> thus, no Cairo, and no GtkPrint.
> 
> To print, then, I plot my image internally, convert to a pixbuf, read
> the pixel data and output this to a postscript file, i.e., it's an
> image I'm plotting, with a little bit of text thrown in.
> 
> I realize that with the advent of Cairo and GtkPrint, this solution is
> dated.  However, in order to convert to the current standard, I would
> need to modify all of my gdk_* drawing calls to Cairo equivalents
> (and a little re-architecting), not something I currently have the
> luxury to do.
> 
> What I was wanting to do, then, was to take advantage of the new
> GtkPrint dialog (specifically, that it knows about all printers,
> allowing the user to select one) and send this internally generated
> PS file directly to the selected printer.
> 
> On a different note, a question:  One trick I employ when creating
> the PS file is to plot my image in memory twice as large as the
> screen, save this to the PS file, and then let the printer re-scale
> to fit the page.  Since printers (typically) have a better resolution
> than a screen, this results in a plot that is very sharp, (better
> than what the user sees on the screen even).
> 
> When, one day, I do change all my gdk_* drawing calls to Cairo, will
> I be able to effectuate this extra sharpness as well?  Or must the
> Cairo calls in my GtkPrint callback conform to the paper size?  Or,
> is this not a concern, i.e., the resulting printed image using Cairo
> would be as sharp as possible given that Cairo takes into account the
> available dpi of the selected printer?
> 
> Thanks for the feedback.  At this point I will have to recommend to my
> users that a 3rd party program be used to send the PS file I create
> to a printer.  (There is a nice free-ware version of this
> functionality available, btw.)  Essentially making them have to
> engage in a 2-step process to get a print out of my program instead
> of through a single step.

Interesting.  I have something similar (but a lot simpler) where I do
some postscript generation from tiff files which uses efix.  I can't
now be bothered to convert this to using cairo (or even GDK), and
happily since I use unix-like OSes I can send them to print with
GtkPrintJob directly.

If you really want to use the GtkPrintOperation dialog (which
under windows I believe calls up the native windows dialog) with
minimum effort, and if poppler compiles under windows (I think it
probably does) then I would be inclined to convert the postscript to
pdf, load the pdf file as a poppler document in the begin-print
callback with poppler_document_new_from_file() (and set the GtkPrint
page numbers in that callback from poppler_document_get_n_pages()) and
then print it to the cairo surface in the draw-page callback with
poppler_document_get_page() and poppler_page_render_for_printing().

These poppler functions are part of the poppler glib/cairo interface.  I
have never used them but they look as if they will do what you want.

On converting ps to pdf, you can use ghostscript but you will have to
set the page size by hand (likewise if you happen to use the ps2pdf
bash wrapper script for ghostscript - but I imagine you will not want
to use bash under windows). epstopdf is a perl script which comes with
the tetex package (but the script doesn't need tetex installed to run)
and automatically sets the page size from the bounding box of the ps
file when calling up ghostscript. Despite its name it can be used with
regular postscript as well as eps.

With this approach your users will still have to have ghostscript
installed (and if using epstopdf, also perl).

Chris