Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 188859 - mail-client/evolution-2.10.2 cannot change paper size, permantly set to A4
Summary: mail-client/evolution-2.10.2 cannot change paper size, permantly set to A4
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: GNOME Office (OBSOLETE)
URL: http://bugzilla.gnome.org/show_bug.cg...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-14 16:58 UTC by scott lorberbaum
Modified: 2008-01-01 19:06 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description scott lorberbaum 2007-08-14 16:58:29 UTC
The Paper size in Evolution can not be changed and when saying File->Print <Print> The job always gets sent to the printer for an A4 paper size. This cannot be changed. Apparently A4 is hardcoded into Evolution 2.10 and has been a problem on other distributions. See https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/86426 which has the same problem.  I've tried many things, including, setting /etc/papersize, restarting cupsd, rebooting, restarting printers, making sure settings in the program are correct.  Everything worked when using Evolution 2.8 but just upgraded and now printing won't work.

Reproducible: Always

Steps to Reproduce:
1. Open an email in Evolution
2. Goto File -> Print
3. push <print> and see if paper size is set correctly for printer.

Actual Results:  
printing will only occur if your printer is setup to use A4 paper, otherwise problems, depending on the printer, and possibly print driver.

Expected Results:  
Prints correctly with the correct settings used, i.e. paper size, type, etc.

Should be US Letter Size   i.e.  na_letter in the Evolution code

none at this time
Comment 1 Gilles Dartiguelongue (RETIRED) gentoo-dev 2007-08-14 20:11:16 UTC
This is enterily an upstream problem I'm afraid. The printing refactoring stuff was splited in 2 parts, the one that got release with evo-2.10 is known to have this problem. This is fixed in 2.11, not sure for 2.10.3 (prolly not).
Comment 2 scott lorberbaum 2007-08-14 21:32:20 UTC
(In reply to comment #1)
> This is enterily an upstream problem I'm afraid. The printing refactoring stuff
> was splited in 2 parts, the one that got release with evo-2.10 is known to have
> this problem. This is fixed in 2.11, not sure for 2.10.3 (prolly not).
> 

Well then how can the package be considered stable? i know it won't crash, but this is a big issue. Not everyone who uses this program version can print, maybe some people can, depending on if they actually use A4 paper, or if their printer supports defaulting to an alternative. I wouldn't have emerged this package had i known the fact that it currently only prints to A4, or print to file and then open. I could have just stuck with 2.8.  I actually had to downgrade to 2.8 which brought up numerous other problems of which i resolved.  But what can be done with this?

An update so that 2.10 or 2.11 has it resolved?
Mark the package different than stable,and wait for the fix in 2.10?
Mark the package different than stable and wait for the next version 2.11 that has the fix?
Don't do anything to the package and see what happens?

I just don't see how you guys can commit the package and mark it as stable with an issue like this, or whoever did it, not to point any fingers directly.

This issue has been around for some time, and 2.10 was still released with the flaw!!
Comment 3 Gilles Dartiguelongue (RETIRED) gentoo-dev 2007-08-14 22:14:57 UTC
upstream considered it was ok to do things like this and the work on upstream bug seem not finished yet (http://bugzilla.gnome.org/show_bug.cgi?id=446894).

I'll wait on input from other devs at this point.
Comment 4 scott lorberbaum 2007-08-14 22:37:32 UTC
(In reply to comment #3)
> upstream considered it was ok to do things like this and the work on upstream
> bug seem not finished yet (http://bugzilla.gnome.org/show_bug.cgi?id=446894).
> 
> I'll wait on input from other devs at this point.
> 

thanks
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2007-08-15 06:50:19 UTC
(In reply to comment #2)
> I just don't see how you guys can commit the package and mark it as stable with
> an issue like this, or whoever did it, not to point any fingers directly.

I'm afraid that printing to US letter paper format is *not* a core function of a mail client, really don't see why this should prevent the new version from going to stable. ;)
Comment 6 scott lorberbaum 2007-08-15 07:08:41 UTC
(In reply to comment #5)
> (In reply to comment #2)
> > I just don't see how you guys can commit the package and mark it as stable with
> > an issue like this, or whoever did it, not to point any fingers directly.
> 
> I'm afraid that printing to US letter paper format is *not* a core function of
> a mail client, really don't see why this should prevent the new version from
> going to stable. ;)
> 

Well its not really a question of stability, so I kindof agree with you on that point.  The program is stable.

But I think it's a usability issue.  If there is a large majority of people out there who uses Evolution and prints to Letter size paper, regardless of it being US or not, shouldn't that be told to the user before they update that hey, what you had in the last version, the ability to print to the paper size you normally print to, yeah its gone in this version. Either goto a different distribution that fixed the problem or wait for the upgrade and go buy some paper in a different size!!!

It seems confusing to me that I update to a new version of a stable package, only to lose what is considered now a standard thing, printing directly from the program without going through loops to get the document to come out on the printer, on the right paper size.

Now I know that these things are simple on the outside, and are quite complex and entangled and cross-coded sometimes in the inside, which might make it difficult to have this feature, but you can't get rid of a standard feature like that.

It may be the case that nothing can be done, until the next version 2.11 because of some other issues, but what of the people who emerge to 2.10? what happens to all those people?  Are they going to consider the package as stable?  Again not in quite the literal sense.

My thoughts.
Comment 7 Mart Raudsepp gentoo-dev 2007-08-15 12:52:56 UTC
(In reply to comment #6)
> Well its not really a question of stability, so I kindof agree with you on that
> point.  The program is stable.

The point here is that it is MORE stable than 2.8, as far as crashing is concerned. Many want a non-crashing mail client instead of printing to non-A4. For example I never print my mails, and if I did I have A4 as I live in the Europe. Nevertheless, see below

> Either goto a different
> distribution that fixed the problem or wait for the upgrade and go buy some
> paper in a different size!!!

If you can point at a distribution that has this fixed we'd be glad to grab the patch they are using to fix this and fix this for Gentoo as well.
Comment 8 scott lorberbaum 2007-08-15 22:41:00 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Well its not really a question of stability, so I kindof agree with you on that
> > point.  The program is stable.
> 
> The point here is that it is MORE stable than 2.8, as far as crashing is
> concerned. Many want a non-crashing mail client instead of printing to non-A4.
> For example I never print my mails, and if I did I have A4 as I live in the
> Europe. Nevertheless, see below
> 
Agreed, it's more stable and crashes less than 2.8, but isn't there anyway to have the program look at something like /etc/papersize instead of hardcoding A4?
Sure it's fine for you, but you have a biased opinion, being that it is hardcoded for the paper size you use.  This program isn't only used in Europe, it's used all over the world! So is gentoo linux.  So hardcoding the paper size seems a little out of place. Upgrade a program so it doesn't crash as much, but downgrade a feature in the program and lose functionality?

> > Either goto a different
> > distribution that fixed the problem or wait for the upgrade and go buy some
> > paper in a different size!!!
> 
> If you can point at a distribution that has this fixed we'd be glad to grab the
> patch they are using to fix this and fix this for Gentoo as well.
> 

 I'll look into it. I thought there was a patch or fix or something.  Many people have talked about going in the code before you compile and changing the hardcoded value to what is needed.  But in gentoo all the compiling is done through emerge, no one wants to step through the emerge and after unpacking the sources, editing the file to their liking, then continuing with the emerge.
Comment 9 Gilles Dartiguelongue (RETIRED) gentoo-dev 2008-01-01 19:06:59 UTC
this is fixed in evolution 2.12 which has been stable for some weeks (if it's not fixed then please reopen this bug).