Windows printing problem
Hi,
I have an app that prints 2 pages with an image in one corner of the
page, and some plotted data in the middle, the rest is text.
The page is oriented in landscape.
On Ubuntu the printing works fine.
On Windows XP I can get the text only to work.
Printing the image creates blank pages.
Printing the plotted data causes printing errors.
I'm using gtk+-bundle_2.18.7-20100213_win32
Any clues?
Code below.
Regards,
James.
pb = gdk_pixbuf_new_from_file(./Logo.jpg, gerror);
if(!pb) {
eprintf(error message: %s\n, gerror-message);
return;
}
int pb_width = gdk_pixbuf_get_width (pb);
int pb_height = gdk_pixbuf_get_height (pb);
//set to 1 makes the whole page blank on Win32, Linux fine.
#if 0
cairo_surface_t *image = cairo_image_surface_create_for_data(
gdk_pixbuf_get_pixels(pb),
CAIRO_FORMAT_RGB24,
pb_width,
pb_height,
gdk_pixbuf_get_rowstride(pb));
do {
int rowstride, n_channels, x, y;
guchar *pixels, *p, tmp;
pixels = gdk_pixbuf_get_pixels (pb);
rowstride = gdk_pixbuf_get_rowstride(pb);
n_channels = gdk_pixbuf_get_n_channels (pb);
for (y = 0; y pb_height; y++) {
for (x = 0; x pb_width; x++) {
p = pixels + y * rowstride + x *
n_channels;
tmp = p[0];
p[0] = p[2];
p[2] = tmp;
}
}
} while (0);
cairo_save (cr);
cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
cairo_set_source_surface(cr, image, 0, 0);
cairo_paint (cr);
cairo_restore (cr);
cairo_surface_destroy(image);
#endif
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Windows printing problem
Hi,
I've refined the code a bit.
This I can print to PDF using pdfFactory Pro, and it is displayed in the
pdfFactory Pro preview window properly, but Windows always errors out on
the actual printing.
Printing direct to the printer (HP laserjet) also causes windows to
report an error trying to print.
(The printer works fine for every other app on Windows and Ubuntu).
Draw page code below.
Regards,
James.
static void draw_page (GtkPrintOperation *operation,
GtkPrintContext *context,
gint page_nr,
gpointer user_data)
{
g_print(Draw page %d\n, page_nr);
int i;
char text[256];
int len;
PangoLayout *layout;
PangoFontDescription *desc;
GError *gerror = NULL;
GdkPixbuf *pb;
cairo_t *cr;
gdouble width, height;
cr = gtk_print_context_get_cairo_context (context);
width = gtk_print_context_get_width (context);
height = gtk_print_context_get_height (context);
pb = gdk_pixbuf_new_from_file(./Logo.jpg, gerror);
if(!pb) {
eprintf(error message: %s\n, gerror-message);
return;
}
int pb_width = gdk_pixbuf_get_width (pb);
int pb_height = gdk_pixbuf_get_height (pb);
cairo_operator_t op = cairo_get_operator(cr);
cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
gdk_cairo_set_source_pixbuf(cr, pb, 0.0, 0.0);
cairo_paint (cr);
cairo_set_operator(cr, op);
cairo_set_source_rgb (cr, 0.0, 0.0, 0.0);
layout = gtk_print_context_create_pango_layout (context);
desc = pango_font_description_from_string (sans 14);
pango_layout_set_font_description (layout, desc);
sprintf(text, Title details);
cairo_move_to(cr, pb_width+10, 0);
pango_layout_set_text (layout, text, -1);
pango_cairo_update_layout (cr, layout);
pango_cairo_show_layout (cr, layout);
pango_layout_set_text (layout, text, -1);
pango_font_description_free (desc);
g_object_unref (layout);
for (i = 0; i 6; i++) {
layout = gtk_print_context_create_pango_layout (context);
len = 0;
len += sprintf(text[len], Stuff\n);
len += sprintf(text[len], More stuff\n);
pango_layout_set_text (layout, text, -1);
desc = pango_font_description_from_string (sans 9);
pango_layout_set_font_description (layout, desc);
pango_font_description_free (desc);
pango_cairo_update_layout (cr, layout);
cairo_move_to(cr, (5 - i) * (width - GAP_X_AXIS) / 6, height -
80);
pango_cairo_show_layout (cr, layout);
g_object_unref (layout);
}
cairo_translate(cr, 0, pb_height);
if (page_nr == 0) {
#if 1
//Various text and line drawing
//with pango and cairo functions.
#endif
} else if (page_nr == 1) {
#if 1
//Various text and line drawing
//with pango and cairo functions.
#endif
}
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 11:13 -0500, Federico Mena Quintero wrote: On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote: [Border around windows so you can glow around a widget] There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. Hmm. I just think it's overkill to complicate the GdkWindow abstraction just for themes' sake. Correct me if I'm wrong, but I think you imagine the glow-around-a-button to actually have allocated space around the button * +--+ * +--+ * |button| * |button| * +--+ * +--+ while I'm imagining that the glow actually overlaps anything around the widget ** * +--+ +*-+ * |button| |*utton| * +--+ +*-+ ** The latter is doable if the theme creates a temporary window as a child of the toplevel, on top of all the other subwindows. Themes can't generally modify the window hierarchy or have other state like this. They just affect the drawing of the widget. [Do we just lack the don't clip flag on windows] To fully take advantage of it we would also like to remove no-window widgets in Gtk and make getting a standard window easy via some default realize handler setup. I guess InputOnly windows are trivial when we get the transparent windows we've been talking about - you just never draw to them. Old apps could still use them to get events. We already support InputOnly windows fine in csw. Getting rid of no-window widgets would be trivial in GTK+, but it would break a lot of code that already uses that trick and does all the coordinate-munging on its own... maybe we should make no-window mean you won't know it, but you really get a cairo_t with a transformation relative to your parent widget? That way you still have to make the changes to take a cairo_t instead of a GdkWindow (for the draw() method), but you don't have to change your delicate code that deals with coordinates. The problem with no-window widgets is not really for the no-window widget, but rather that all parents must have special expose code that chains to the no-window widgets. If we want to clean up the drawing code this is kinda ugly. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a benighted arachnophobic librarian with a robot buddy named Sparky. She's a mistrustful red-headed bodyguard fleeing from a Satanic cult. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK schedule adjustments
I thought it would probably be a good idea to announce these separately, instead of hiding them in the team meeting minutes. So, after GTK+ 3 got moved back to December at GUADEC, we've decided that we will do a GTK+ 2.24 release in parallel. GTK+ 2.22 will be released together with GNOME 2.32 in September. The main reason for the 2.24 release is to make new API available in the 2.x stream that might be needed for the next part of the rendering cleanup work (pixmap removal). In the same vein, there will also be a GLib 2.28 release to go along with GTK+ 3. In summary: - glib 2.26 and gtk+ 2.22 for GNOME 2.32 (Sep '10) - glib 2.28, gtk+ 2.24 and gtk+ 3.0 for December '10 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Thu, Aug 19, 2010 at 10:08 AM, Alexander Larsson al...@redhat.com wrote: The problem with no-window widgets is not really for the no-window widget, but rather that all parents must have special expose code that chains to the no-window widgets. If we want to clean up the drawing code this is kinda ugly. I think this is a crucial question we need to answer about future GTK/GDK: Who should be responsible for chaining up to children? (Note that this question is not just interesting for drawing, but also relevant for event handling.) Currently everybody does at most half of this job: GDK does it for windows, GTK does it for drawing on no-window widgets (with gtk_container_propagate_expose()). GtkWindow does it for key presses. In my ideal world, the containers are responsible for bubbling up drawing commands and events. For gtk_widget_draw(), this is pretty much a requirement. Otherwise we'd need to duplicate the GDK functionality into that function (just lik gtk_widget_get_snapshot() does now). Also, relegaing this job to Gtk allows much more flexibility in creating widgets because one is not bound by the limitations of GDK as one translates events oneself. So things like Coverflows get possible. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Installing GTK Binary Packages Into MINGW on MS Windows Using Wascana and Eclipse
Øystein Schønning-Johansen wrote: On Wed, Aug 18, 2010 at 8:07 PM, Peter Willis pwil...@aslenv.com mailto:pwil...@aslenv.com wrote: Hello, I would like to use mingw to port and compile a simple GTK application under MS Windows. The download page for windows located at: http://www.gtk.org/download-windows.html recommends the mingw tool chain and contains tables of relevant packages as well as dependencies. I have downloaded the various required packages and dependencies marked 'Dev' on that page. What is unclear from any installation instructions I have been able to find is where and how to install these packages into mingw. Do I simply decompress the archives in the mingw directory hierarchy so that the files end up in the respective directories there? *or* Do I need to make separate hierarchies for each of the zip files and point GCC at the 'lib' and 'header' directories using '-L -l' and '-I -i' flags respectively? I've used GTK and glib with mingw for many years now, and I've always put mingw in c:\mingw and all the gtk stuff in c:\gtk. This works perfectly, and I usually also add some simple unix-ish tools such that I can mimic a unix system at a dos prompt. To make all include and linking simple I usually have a makefile that contains these lines: INCLUDE = -I/C/GTK/include $(shell pkg-config --cflags gtk+-2.0) LIBS = $(shell pkg-config --libs gtk+-2.0) ... or somthing similar depending on what I need. I would not recommend to put GTK and MinGW in the same directories! -Øystein Thanks, That's perfectly what I needed to know. I am using the 'wascana' build of eclipse IDE, which has mingw included in the package. Do you have any opinions regarding using this? My first sense was to avoid it, but I prefer the IDE and it saves me some work. One other question I have is regarding packaging of the final application along with the GTK runtime for windows. How problematic are the version differences in runtime DLLs? Will making an installer that includes GTK runtime of a different version break GTK software that people have previously installed? Does it matter? I don't want to break everyone's Gimp. Peter ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
