GNOME Bugzilla – Bug 115476
Causes loss of paper size and orientation settings in gnumeric
Last modified: 2009-05-16 10:08:07 UTC
[originally filed as http://bugs.debian.org/195600 ] From: "Alex. M." <debian-bugs@tagancha.org> Date: Sat, 31 May 2003 16:03:39 -0500 Package: gnumeric Version: 1.1.17-3 Severity: important Tags: upstream As subject says. I can't make it retain the landscape orientation setting either from "File/Page Setup" or "File/Print/Paper". It always reverts to Portrait. From: Adam Kessel <adam@bostoncoop.net> Date: Wed, 18 Jun 2003 09:55:00 -0400 Subject: gnumeric: Can't print landscape--is there any workaround? Package: gnumeric Version: 1.1.19-1 Followup-For: Bug #195600 I just wanted to confirm this bug occurs on all installations I've seen out of unstable--can't print landscape. It makes gnumeric almost useless for printing when all of one's spreadsheets were set up to be landscape. Is there any temporary workaround for this bug? Can I put in a pitch to up its priority?
This really seems to be 110278 which is believed to be a gnome-print bug. Do we have any evidence one way or another?
Well, I don't think it's a gnome-print bug. In fact I believe it fixed in cvs (and therefore all version 1.1.20 onwards when they appear).
I just tested it with CVS and it seems to be fixed indeed. Good to hear!
Well, stop the celebrations. It worked under certain circumstances only. Specifically only if the gnome-print-config in use was not loaded from a string. During my fix I happened to unintentionally remove that load which kills the establishment of a default setting for the user. When I fixed it the landscape setings didn't stick any more (unless the gconf setting was wiped before starting gnumeric). Well, it is currently working in cvs but we still have to address what looks like a gnome-print-config bug. I am reopening this bug to remind us of the costs of fixing it.
I believe this to be fixed now.
We don't seem to have the issue with libgnomeprint 2.5.x and the gnome 2.5 stuff, but the problem remains with gnome 2.4 (and libgnomeprint 2.4.x).
*** Bug 142348 has been marked as a duplicate of this bug. ***
Then let's wontfix the remainder. If the core of the patch is on the libgnomeprint side there is little utility in backporting the change to old variants of libgnomeprint. The release mechanism there was jsut too hairy.
The problem still persists for me using an up to date sid system + experimental's GNOME 2.6 packages: gnumeric 1.2.12-1 libgnomeprint2.2-0 2.6.1-5 libgnomeprintui2.2-0 2.6.1-3 1. Start gnumeric. 2. Enter 'A' in A1. 3. Select File -> Print Preview. [A portrait preview. OK.] 4. File -> Save as "a.gnumeric". 5. Set File -> Page Setup -> Page Orientation to Landscape; OK. 6. Select File -> Print Preview. [A landscape preview. OK.] 7. File -> Save as "b.gnumeric". 8. Exit gnumeric. 9. Run "zcat a.gnumeric > a.txt ; zcat b.gnumeric > b.txt ; diff -u a b". [The only difference is in the <gmr:orientation> tag. a has "portrait"; b has "landscape". OK.] 10. Run "gnumeric b.gnumeric". 11. Select File -> Print Preview. [A portrait preview. *Bug*] 12. Exit gnumeric. 13. Run "gnumeric b.gnumeric". 14. Look at File -> Page Setup -> Page Orientation. [It's set to "portrait" rather than "landscape". *Bug*] It seems like the paper orientation is being ignored on load.
This is a special case of #136206; perhaps the reports should be merged?
*** Bug 136206 has been marked as a duplicate of this bug. ***
I've done some testing (gnumeric 1.3.91+ (HEAD)), libgnomeprint2.2-0 (2.8.0.1-1). The problem is still reproducible. When File -> Print Preview or File -> Page Setup is chosen, the information that's stored in a GnomePrintConfig (like physical paper size and orientation) is lost. print_info_dup() is called; it calls print_info_new() which calls gnome_print_config_from_string(). That call to gnome_print_config_from_string() corrupts print_info_dup()'s src_pi. I'm reassigning accordingly.
I've been poking at this bug, which is preventing me from printing in landscape mode from Evolution. I am testing/debugging using the print preview. When the preview first opens, the page appears in landscape mode. A split second later it refreshes, and the paper remains in landscape mode, but the content is in portrait mode (extends off the page). When I actually try to print, it goes off the page -- so the preview is at least accurate. ;) The refresh occurs when update_func() (in libgnomeui/gnome-print-job-preview.c) is called, which is invoked by gtk after the window is drawn (via g_idle_add_full()). Initially, the value corresponding to the 'Settings.Document.Page.LogicalOrientation.Page2LayoutTransform' key is "matrix(0 1 -1 0 0 1)" (the transform corresponding to landscape). However, at some point after the preview is initially rendered and when update_func is called, the value is changed to "matrix(0 1 -1 0 0 1)" (portrait). It also appears that the address of the GPANode corresponding to 'Settings.Document.Page.LogicalOrientation.Page2LayoutTransform' does not change (although the value of the node does change). This means that the entire GnomeConfig is not being recreated/replaced. What I can't figure out is what is causing the config to change. I set a bunch of breakpoints on likely functions (gnome_print_config_from_string, etc.), but can't figure out where/when the change is occurring. I hope this information will help someone else to solve this -- at the moment I'm stuck.
Having followed JHM's recipe in #9, I get landscape preview and printing. This is with HEAD gnumeric, libgnomeprint and libgnomeprintui. However, if you choose another printer than the default, you get the page orientation and paper size which are default for that printer.
*** Bug 323263 has been marked as a duplicate of this bug. ***
*** Bug 442799 has been marked as a duplicate of this bug. ***
I can confirm that it is libgnomeprint!! Have been trying to get my application developing to print my html tables. Developing it with wxPython/wxGTK. After changing my settings in the PrintDialog to landscape, either manually or in the code, then click 'Print Preview'. What you get is the paper has changed to landscape, but the contents are still in portrait. If you actually print it out, that is how it prints also. I tested this out with gnumeric also and same results. Here are the versions of libgnomeprint I had: 2.18.0 So emerged (gentoo speak) 2.12.1 and problem gone. Landscape changes the paper and contents correctly. Reinstalled 2.18.0 and problem came back. I haven't tried anything from cvs cause gentoo still has 2.18.0 masked and not stable. But it def was libgnomeprint-2.18.0
(In reply to comment #17) I can also confirm that it is indeed libgnomeprint and libgnomeprintui; the issue is still present in Gentoo. At least version 2.18 is broken; only 2.12 works. See Gentoo's bug here: http://bugs.gentoo.org/show_bug.cgi?id=191204
Is there really still any development happening in gnome-print?
(In reply to comment #19) > Is there really still any development happening in gnome-print? Given the open bugs, I hope so! If not, what's the replacement, if any? I have yet to find anything on the website or discussion in the lists.
I was worried about current development also. Using wxPython and thru the wxWidgets (wxGTK), it uses this for printing. I have found references that this package might be replaced, but no solid evidence to support what might replace it. As far as wxGTK goes also, the developers don't seem to be thinking it is going to be replace or at least they don't appear to be making any moves to support something else. Not too long ago I had some bugs fixed with the way wxGTK was working with gnomeprint. They made no mention to me that the fixes were temp until they replace it with something else. So I hope this is still being worked on or at least maintained.
libgnomeprint/libgnomeprintui are to be deprecated in favour of the printing support in GTK+. I think there are tutorials on how to port to it as well. Have you looked at that?
(In reply to comment #22) > libgnomeprint/libgnomeprintui are to be deprecated in favour of the printing > support in GTK+. I think there are tutorials on how to port to it as well. Have > you looked at that? Any word on fixing this? The latest releases, libgnomeprint-2.18.4 and libgnomeprintui-2.18.2, are *still* broken. This should be old news -- does Gnome 2.20/2.22 really need runtime dependencies on these broken libraries, or will the printing support in gtk-2.12.8 work for all apps? Abiword in particular has always used libgnomeprint & friends; I'd hate to go breaking my desktop apps left and right because they won't work with the new printing support in gtk+.
Abiword has finally been ported to use Gtk+ printing in the current 2.7.x development series. That was the last app to use libgnomeprint on my system at least. libgnomeprint development has been non-existant the last couple of years aside from the odd build fix etc.