Re: [Gimp-developer] Print Dialog - Seg faults in 2.4RC1
Von: Tim Jedlicka [EMAIL PROTECTED] When I select the Print button, I get a segmentation fault: [...] Anything obvious I should check. Bugzilla - http://bugzilla.gnome.org/browse.cgi?product=GIMP. It might also be useful to watch the Bugzilla user bugs(at)gimp.org, you will then receive mail notifications of changes (granularity is configurable) to bugs in the GIMP product. You would most likely have noticed bug http://bugzilla.gnome.org/show_bug.cgi?id=467643 or one of its duplicates then. HTH, Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Print Dialog - Seg faults in 2.4RC1
When I select the Print button, I get a segmentation fault: /opt/gimp-2.4/lib/gimp/2.0/plug-ins/print: fatal error: Segmentation fault I'm guessing I'm missing something basic. I downloaded and compiled gtk+- 2.10.13, then compiled gimp2.4rc1 with PKG_CONFIG_PATH set to include the gtk2.10.13 package. Anything obvious I should check. -- Tim Jedlicka, Network Entomologist [EMAIL PROTECTED], http://www.galifree.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Print dialog
Hi, over the last days I have tried to get the new print plug-in into a state that is good enough for the 2.4 release. There are however still a number of issues. I will paste from bug #387604 because it makes more sense to discuss this here than in Bugzilla: Three minor issues: - It comes up in mm: seems like this should be inches (since other prefs, such as resolution of the default new image and the units shown in the default grid prefs are in inches), or at least that I should be able to change it to inches and have it remember (it doesn't). The dialog comes up with whatever unit is default for your locale. This is also the behavior of the Print Size dialog in the core. So either that's fine or we also need to change the way the core dialog works. - The Adjust Page Size and Orientation button brings up a subdialog that still calls itself Page Setup. The dialog title seems to be hardcoded in GTK+. I would very much welcome if we could embed these widgets instead of having them in a popup dialog. The dialog is even modal. There's supposedly an API to make it asynchronous (gtk_print_run_page_setup_dialog_async). But since changes in the dialog are only applied when the user presses the Apply button and since this dismisses the dialog, I consider this API broken. - In that subdialog, the default is Any Printer (for portable documents), which seems strange since the default in the main tab is the system printer, not print to file. Shouldn't the default in the subdialog be the printer that's currently chosen. Yes, indeed. I think it should do that. We should report this as a bug to GTK+. More important (and perhaps related?) issues: - The Page Setup dialog still chooses a page size of A4 every time even though my system default is Letter and I've chosen Letter in past runs of the dialog. This probably needs to be fixed in GTK+. Or someone who really understands GtkPrint needs to have a look at our code and tell us what we are doing wrong here. - Clicking Print Preview still dismisses the dialog without doing anything. It is supposed to call the default document viewer, which is evince on my system. If that doesn't work for you, better file a bug report for it against GTK+. - Clicking Print seems to get stuck if the printer isn't on when I click it. The progress bar goes to 100% and then stays there, and nothing shows up in the print queue. Subsequently turning the printer on doesn't help. If the printer is on when I click Print, it does eventually send something to the print queue (though it takes a surprisingly long time, even for a small image in Draft mode, compared to the gimp-print plug-in). I have improved the status messages a little since you reported this. Printing is still rather slow though. I am not sure if and how this can be improved. Again, we seem to need advice from a GtkPrint expert here. - When I print using this plug-in, I get periodic horizontal light bands. I'll do more testing, but I think it's something this plug-in is doing (not a clogged nozzle on my printer or similar issue) because I can print at different scales and resolutions and the bands always show up at the same places relative to the original image, regardless of physical spacing on the page. Yes, the banding comes from the fact that the plug-in paints the image in stripes of tile height. It does that to avoid having to allocate memory for the whole image. I hope that we can find a way to fix this. - If I print to file (PDF), I don't see the banding but I do see a spurious edge effect: it looks like the leftmost few columns of pixels are duplicated over on the right side of the image. I can attach a sample PDF if anyone wants to see one. I can't reproduce that. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print dialog
From: Sven Neumann [EMAIL PROTECTED] Date: Fri, 29 Dec 2006 17:18:58 +0100 - Clicking Print seems to get stuck if the printer isn't on when I click it. The progress bar goes to 100% and then stays there, and nothing shows up in the print queue. Subsequently turning the printer on doesn't help. If the printer is on when I click Print, it does eventually send something to the print queue (though it takes a surprisingly long time, even for a small image in Draft mode, compared to the gimp-print plug-in). I have improved the status messages a little since you reported this. Printing is still rather slow though. I am not sure if and how this can be improved. Again, we seem to need advice from a GtkPrint expert here. The hang could also be a spooler issue. Unless GtkPrint is doing some kind of special checking (or you're not using a spooler), it shouldn't even know if the printer that the printer isn't on. - When I print using this plug-in, I get periodic horizontal light bands. I'll do more testing, but I think it's something this plug-in is doing (not a clogged nozzle on my printer or similar issue) because I can print at different scales and resolutions and the bands always show up at the same places relative to the original image, regardless of physical spacing on the page. Yes, the banding comes from the fact that the plug-in paints the image in stripes of tile height. It does that to avoid having to allocate memory for the whole image. I hope that we can find a way to fix this. How would this kind of banding affect the output? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print dialog
Hi, On Fri, 2006-12-29 at 11:29 -0500, Robert L Krawitz wrote: Yes, the banding comes from the fact that the plug-in paints the image in stripes of tile height. It does that to avoid having to allocate memory for the whole image. I hope that we can find a way to fix this. How would this kind of banding affect the output? The spans that we are painting on the cairo surface are in image coordinates. These coordinates do not necessarily fall on the device pixel grid. I assume that cairo then applies antialiasing on the borders of the span. This results in the thin white stripes that Akkana reported. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
