After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 140203 - Win32 GDI printer support
Win32 GDI printer support
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Backend: Win32
unspecified
Other Windows
: Normal enhancement
: Medium feature
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2004-04-15 20:29 UTC by John Ehresman
Modified: 2006-03-28 04:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Initial hack for printing (5.74 KB, patch)
2004-04-15 20:31 UTC, John Ehresman
none Details | Review

Description John Ehresman 2004-04-15 20:29:39 UTC
Attached is a hack to enable printing through the Windows gdi.  I don't think it
should be applied as is because it abuses the gdk_pixmap_foreign_new function
and isn't that clean -- you can probably crash it by trying to render a pixmp. 
Rather, I want some feedback on whether this could go in.  I realize there is
talk of using cairo for printing, but I'm interested in something that works
now.  With this patch, the scintilla widget can print using it methods that were
designed to work natively on win32.

The patch works by modifying gdk_pixmap_foreign_new to accept a device context
handle and using that handle in subsequent drawing calls.  A
gdk_pango_context_get_for_drawable function is also added that will return a
pango context appropriate for printing; which works by using new pango functions
defined the pango patch attached in
http://bugzilla.gnome.org/show_bug.cgi?id=140199  Code that wants to use this
printing support is responsible for setting up the hdc (usually via the PrintDlg
win32 api call) and starting / ending each page via win32 api calls.

If there is interest, the direction I'd probably take this is to create a new
drawable subclass for the printer support and add functions to it to support
starting and ending pages, starting and ending jobs, and expicitly closing the
printer DC.
Comment 1 John Ehresman 2004-04-15 20:31:36 UTC
Created attachment 26702 [details] [review]
Initial hack for printing
Comment 2 Owen Taylor 2004-04-16 18:32:48 UTC
I don't think this should be added like this. We do want cross-platform
printing support in GTK+ eventually, but it will be based on Cairo
(http://www.cairographics.org) not the current GDK API.
Comment 3 John Ehresman 2004-04-16 18:47:37 UTC
The advantage of exposing printing through the GDK api is that code that is
already writteen to use it can be modified to support printing.  As I said
before the scintilla widget currently works with this patch and I could envision
modifying GtkTextView to work in much the same way.  I know that the gdk api has
its limitations, but it's good enough for a lot of purposes.

I guess I'm making the case for implementing an imperfect solution now rather
than waiting for better tools to be available later.
Comment 4 Owen Taylor 2004-04-16 20:24:50 UTC
I don't want to add code and API (and the code would be a lot bigger
and more complicated for X11) that is going to be abandoned in a 
1 year timeframe.
Comment 5 John Ehresman 2004-04-16 20:43:08 UTC
Okay, I'll attempt to do this as outside gdk by creating a drawable subclass in
my code and passing it in.  It would be nice, though, to be able to use the gdk
api even when cairo is available (perhaps via calldowns to the cairo layer) so
that widgets like scintilla that don't require advanced rendering don't need to
target yet another drawing api.

I'd like to leave this bug open for patches to gdk that may be required so that
an external drawable can work.
Comment 6 Dominic Lachowicz 2006-03-28 03:41:07 UTC
John, now that GTK+ and Cairo integration largely works, and GTK+ printing has been merged onto the gtk-print branch, do you think that this bug should be open? Thanks.