364842 - Printing: Color chosen but no color results - Page B&W

Status: RESOLVED INCOMPLETE

(Calendar :: Printing, defect)

Description

[B. Switzer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3

Sunbird.

Reproducible: Always

Steps to Reproduce:
1. Choose color printer. (In my case, my Ricoh CL3000 colour laser is the default.)
2. Choose a month display, e.g. June 2007
3. Page Setup. I chose landscape. Tick Print Background.
4. File Print. Print preview comes up. Change layout to monthly grid. Note - previewed page is in black and white.
5. Print. Results in black and white. (As expected, given 4.)

Actual Results:  
Black & White Print

Expected Results:  
Color Print.

Either, fix so preview is in color, or remove page setup tickbox for color in the meantime. i.e. Don't lead the user on to thinking he can print in color, if he's not going to be able to.

Comment 1

[Stefan Sitter [:ssitter]]

Works for me. 

If I assign colors to my calendars the events are correctly colored in the print output. The background for the day boxes are in different shades in gray because that is specified in the source code [http://lxr.mozilla.org/mozilla/source/calendar/import-export/calMonthGridPrinter.js#72].

If 'Print Background' is disabled everything is printed with white background as expected.

Comment 2

[B. Switzer]

> The background for the day boxes are in different shades in gray
because that is specified in the source code

Well ... I gues my answer is ... fix the source code?

Please take my point, it isn't something that can be debated.

The phrasing leads one to believe the background will print in colour.

Preferably, it really would print in colour.

But if it's not going to, that should be made clear. e.g. Instead of 'Print background (colors and images)', 'Print background (B&W calendar, color entries and images)'.

I say it is, at least, a bug that the phrasing is misleading. Since you say it's in the source code, and the program is behaving as coded / expected, then I suppose this is also an enhancement request. (To have it print in colour.)

Comment 3

[Damian Szczepanik]

If we treat it as a bug
WFM with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070114 Calendar/0.6a1

if as request - severity should go to enh

Comment 4

[cmtalbert]

I have tested this with the a current nightly build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070122 Calendar/0.6a1

I find:
                 Print Background checked           Print Background unchecked
---------------------------------------------------------------------------------
Month View    |    Preview: Color, Print: Color    |   Preview: Color, Print: BW
              |                                    |
Week View     |    Preview: Color, Print: Color    |   Preview: Color, Print: BW
              |                                    |
List View     |    Preview: BW,    Print: Color*   |   Preview: BW,    Print: BW

* In the List View, when it printed in color, it printed a uniform color background to the event title. This color has nothing to do with the color associated with the event's calendar in Sunbird.

Reporter, please test this with a recent nightly build. Perhaps this issue has been fixed since 0.3.

I'm going to mark this as WFM. Reporter, if you can still reproduce this issue with a current nightly build, then post a comment here and we will re-open the issue.

There is an issue with the Print Preview always showing you the events in color, even when you will be printing black and white, and I will file a follow on bug for that.

Comment 5

[B. Switzer]

(A pointer as to how to get the nightly build to test as you request, would be appreciated.)

Please mark this issue as a request for enhancement then. You say the code is working correctly as coded. If so, then I would request the code be enhanced so that when printing in colour is requested, it does so.

I don't really follow your comments in their entirety.

From your chart, in all but one case, if you request colour, preview in colour, a B&W print results. To my mind that is a bug. For various reasons, you disagree, thus your WORKSFORME status.

I really don't understand how the status can be WORKSFORME - a request for a colour print resulting in a B&W print, works?

As I have said, at the least, if the code is not going to produce a colour print, then the text associated with printing should neither list, nor show, a colour preview. i.e. Don't tell me you're going to produce a colour print, then not do so, then tell me here everything is working fine. The descriptive text and the result should match.

If I understand this thread correctly, it seems to me this ticket should be duplicated as an enhancement, and this ticket closed.

An earlier comments stated:
> if as request - severity should go to enh

I would do that but I don't see how at the bottom of this page. Or, I see how that might be done at the top of this page, but I'm not comfortable doing so. And all I mean by that is, I'm too new and unfamiliar with this ticket process to be comfortable that _I_ (of all people!) should be changing ticket items that would appear to impact a lot of other people more familiar with this process than myself.

But I do have to say, to you all ... thanks for being here. I, as a member of the user community, sure do appreciate it.

Comment 6

[cmtalbert]

(In reply to comment #5)
> (A pointer as to how to get the nightly build to test as you request, would be
> appreciated.)
Sorry about that:
http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/2007-01-23-03-mozilla1.8/
I would recommend using creating a new profile for testing by running sunbird.exe -P from the command line or from the "RUN" prompt on the start menu (i.e. c:\Program Files\Mozilla Sunbird\sunbird.exe -p)

> Please mark this issue as a request for enhancement then. You say the code is
> working correctly as coded. If so, then I would request the code be enhanced so
> that when printing in colour is requested, it does so.
> 
I don't believe this is an enhancement request. If you tell the app to print in color, it should print in color.  The entire enhancement/source code business in this bug is a misunderstanding.  I believe Stefan was trying to point out that the printout was in color for him, except the background of the empty days were gray, which is the bit of source code he referenced. I believe that the issue you reported is that your *events* are in black and white when they should be in color. (Please correct me if I'm wrong).

> I don't really follow your comments in their entirety.
> 
> From your chart, in all but one case, if you request colour, preview in colour,
> a B&W print results. To my mind that is a bug. For various reasons, you
> disagree, thus your WORKSFORME status.
Perhaps my chart was not clear. The left hand column of the chart described the behavior of the preview and the printout when the "Print Background Color" was  *CHECKED*. That means we should be printing in color at that point. 

In every case, I got a printout in color.  In the List View, I got a printout in color that was not the color I was expecting. It was a uniform color for every event, a sort of light purple color.  

On the right hand side of the chart, it describes the behavior when the "Print Background Color" was *UNCHECKED*. This means we should have been printing in black and white. In all these cases we did in fact print in black and white.  However, the preview in two of these cases was in color, and I opened bug 367898 for that issue.

I hope that is more clear. If it is not, then perhaps a more interactive medium would help. Please join us on IRC at irc://irc.mozilla.org#calendar-qa (channel is #calendar-qa) and we will get this sorted out.
 
> As I have said, at the least, if the code is not going to produce a colour
> print, then the text associated with printing should neither list, nor show, a
> colour preview. 
We agree with you. What you see in the preview should match what comes out of the printer. It is our intention to offer both color and black and white, and both of those need to work.

 
> If I understand this thread correctly, it seems to me this ticket should be
> duplicated as an enhancement, and this ticket closed.
no need for that. As I said, it is not an enhancement, it is a bug. But, I think the bug has been solved in the latest nightly build.

> I would do that but I don't see how at the bottom of this page. Or, I see how
> that might be done at the top of this page, but I'm not comfortable doing so.
> And all I mean by that is, I'm too new and unfamiliar with this ticket process
> to be comfortable that _I_ (of all people!) should be changing ticket items
> that would appear to impact a lot of other people more familiar with this
> process than myself.
That's fine. It's best to err on the side of caution in bugzilla.

> But I do have to say, to you all ... thanks for being here. I, as a member of
> the user community, sure do appreciate it.
> 
Thanks. And thank you for letting us know about the bug.  We always appreciate knowing about bugs that people find, and we take them all seriously.  However, some days we find ourselves scrambling beneath a mountain of bugs, and the comments can get pretty terse. I apologize for the confusion.

--- My Recommendation --
Try out the nightly build
Use a clean, testing profile
See if it fixes the printing problem.
Report back here if it fixes it or if it does not fix it.

I will hold the bug open until we hear from you.

If you have any issues, please log onto IRC and we will work through them together. (Server: irc://irc.mozilla.org Channel: #calendar-qa) My nickname on there is ctalbert.

Comment 7

[cmtalbert]

Sorry for the bugspam, but there are instructions for backing up your profile on our test day page here: http://wiki.mozilla.org/Calendar:Current_QA_TestDay#BEFORE_YOU_START--BACKUP_YOUR_PROFILE

Comment 8

[B. Switzer]

Thank you kindly for your note - it clarifies a very great deal.

No worries about the 'bugspam' - it's appreciated. I'd rather have someone reiterate something I know about, that not be aware of it at all.

Let me get back to you.

Comment 9

[Marco van Beek]

I agree there was a problem with this, way back in maybe v0.3, but I just checked and colour prints fine. What is still annoying is the lack of the option to print a legend or a name tag to tell you what each colour represents when you want to print calendars for more than one person. See Bug 394011 for what mean.

Comment 10

[Martin Schröder [:mschroeder]]

No response from reporter. Feel free to reopen the bug report if you can still
reproduce. -> Resolving as INCOMPLETE.