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 566147 - Reading out papersize from a saved PageSetup seems to fail,
Reading out papersize from a saved PageSetup seems to fail,
Status: RESOLVED INVALID
Product: gtkmm
Classification: Bindings
Component: general
2.4
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2008-12-31 15:51 UTC by Tor Krill
Modified: 2009-01-22 11:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Short app showing the problem. (1.19 KB, application/x-compressed-tar)
2009-01-01 21:48 UTC, Tor Krill
Details

Description Tor Krill 2008-12-31 15:51:49 UTC
Please describe the problem:
In my application, basically the print example from gtkmm docs, when the user has done a page setup to configure the page setup i save this with the save_to_file method. (And i do the same with the printer settings to select the right printer)

When restarting the application i read this back when creating the new pagesetup (And print settings). But doing this it seems like the papersize gets wrong for some reason.

Dumping initial values after page setup in application gives:

Display name: Standard Address Label (29 x 90mm)
Name        : ppd_StandardAddressLabel
PPD name    : StandardAddressLabel
Is custom   : 1
Height      : 89.9583
Width       : 28.9278
Def bot marg: 6.35
Def top marg: 6.35
Def lft marg: 6.35
Def rgh marg: 6.35

I then manually set margins to 0 to get correct printing.

The written file looks like this:

[Page Setup]
PPDName=StandardAddressLabel
DisplayName=Standard Address Label (29 x 90mm)
Width=28.927777777777774
Height=89.958333333333329
MarginTop=0
MarginBottom=0
MarginLeft=0
MarginRight=0
Orientation=landscape

Restarting the application reading above and dump it yields:

Display name: Standard Address Label (29 x 90mm)
Name        : ppd_StandardAddressLabel
PPD name    : StandardAddressLabel
Is custom   : 1
Height      : 31.7353
Width       : 10.2051
Def bot marg: 6.35
Def top marg: 6.35
Def lft marg: 6.35
Def rgh marg: 6.35

Where height and width is set wrongly.

I further tried to do the same and use set_paper_size to correct this. But it seems to work as above.


Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Tor Krill 2009-01-01 21:48:37 UTC
Created attachment 125604 [details]
Short app showing the problem.

This is a short snippet of code showing my problem. The attachemt contains a small app reading a provided page setup file.

Cfg says:

[Page Setup]
PPDName=My ppd name
DisplayName=This is a test file
Width=100.0
Height=100.0
MarginTop=1.0
MarginBottom=1.0
MarginLeft=1.0
MarginRight=1.0
Orientation=landscape

But after reading this file and dump it from app i get:

========= Paper =============
Display name: This is a test file
Name        : ppd_My ppd name
PPD name    : My ppd name
Is custom   : 1
Height      : 35.2778
Width       : 35.2778
Def bot marg: 6.35
Def top marg: 6.35
Def lft marg: 6.35
Def rgh marg: 6.35
========= Pagesetup ==========
Orientation  : 1
Page height  : 33.2778
Page width   : 33.2778
Paper height : 35.2778
Paper width  : 35.2778
Bot margin   : 1
Top margin   : 1
Left margin  : 1
Right margin : 1
Comment 2 Tor Krill 2009-01-01 22:42:09 UTC
Seems like if i read out the values as Gtk::UNIT_POINTS they get reported correctly as read in the pagesetup. But all values should be in MM.

Even constructing a papersize from a keyfile shows the exact same characteristics.
Comment 3 Murray Cumming 2009-01-02 12:09:14 UTC
In my jhbuild (with GTK+ and gtkmm from svn), I get this output, which seems to be correct:

========= Paper =============
Display name: This is a test file
Name        : ppd_My ppd name
PPD name    : My ppd name
Is custom   : 1
Height      : 100
Width       : 100
Def bot marg: 6.35
Def top marg: 6.35
Def lft marg: 6.35
Def rgh marg: 6.35
========= Pagesetup ==========
Orientation  : 1
Page height  : 98
Page width   : 98
Paper height : 100
Paper width  : 100
Bot margin   : 1
Top margin   : 1
Left margin  : 1
Right margin : 1

I wonder if this is a problem in a specific version of GTK+. With the regular GTK+ and gtkmm from my Ubuntu Intrepid, I get this (apparently wrong) output:

========= Paper =============
Display name: This is a test file
Name        : ppd_My ppd name
PPD name    : My ppd name
Is custom   : 1
Height      : 35.2778
Width       : 35.2778
Def bot marg: 6.35
Def top marg: 6.35
Def lft marg: 6.35
Def rgh marg: 6.35
========= Pagesetup ==========
Orientation  : 1
Page height  : 33.2778
Page width   : 33.2778
Paper height : 35.2778
Paper width  : 35.2778
Bot margin   : 1
Top margin   : 1
Left margin  : 1
Right margin : 1

Comment 4 Murray Cumming 2009-01-07 21:04:35 UTC
What versions are you using, on what distro?
Comment 5 Tor Krill 2009-01-08 07:36:40 UTC
I run on Ubuntu 8.10 so it could be some issues in their versions.(And i must say, getting printing working there with gtkmm has turned out to be quite a hazzle)
Comment 6 Murray Cumming 2009-01-19 11:53:41 UTC
Could you file this as a bug in Ubuntu's launchpad then. They probably need to update their version of GTK+. They will probably want a C test case. Feel free to subscribe me or post the URL here so I can subscribe myself.

I'm closing this here because it's apparently not a bug in gtkmm.
Comment 7 Andrea 2009-01-22 11:08:48 UTC
I've had the same problem

http://bugzilla.gnome.org/show_bug.cgi?id=567806

I think the bug only shows up in some cases when the PPD name is not recognized.
I was using GIMP and it works for A4, it does not work for Photo(4x6).

In my opinion the error is in gtk_paper_size_new_from_key_file() which calls gtk_paper_size_new_from_ppd() with
height and width in MM while gtk_paper_size_new_from_ppd() needs POINTS.

There is a patch here

http://mail.gnome.org/archives/gtk-devel-list/2009-January/msg00104.html


I have had this issue in 

Fedora 9  - gtk+2.12
Fedora 10 - gtk+2.14

I patched my version of gtk+2 and everything works.
I have not run the latest svn-trunk but only at reading the code, I can see the same still happening (if I am not wrong).

Thanks
Comment 8 Andrea 2009-01-22 11:44:54 UTC
OK, I was wrong. I has been fixed.
I've found the commit with the fix

21841 on 03/12/2008

I will file a bug in Fedora to release an updated version of GTK+.

Thanks

Andrea