Closed Bug 394681 Opened 17 years ago Closed 15 years ago

emoticons print as squares with strange contents

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: hb9tst, Unassigned)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: 2.0.0.6 (20070728)

When printing a message containing emoticons (having the "Print background" checkbox active so that they get print), instead of getting the emoticons at their place like those shown in the print preview, a rectangle containing many very small emoticons (corresponding to the right emoticon having to be printed at that place) in different colors at the top is printed, with the rest of the rectangle being filled by random pixels.

Reproducible: Always

Steps to Reproduce:
1. Ensure that the "Print background" checkbox is checked.
2. Print a message containing some emoticons
(see additional information)

Actual Results:  
Instead of the emoticons, these rectangles with very small emoticons and random pixels are printed.

Expected Results:  
Like in print preview, having the correct images instead of these.

The emoticons are printed correctly (although with a not so nice black background) if the emoticon drop-down menu of a compose window has been displayed at least once before printing the message.
Attached file An example of the bug
Attachment #279388 - Attachment mime type: application/force-download → application/pdf
Version: unspecified → 2.0
I could reproduce the behavior you describe (including that printing works correctly after opening the emoticon drop-down menu during composition once) on the current Thunderbird 2.0.0.12 (Windows/20080213) version, but not with today's nightly trunk. The emoticon was printed correctly without the workaround with the composition window first.

This bug may have been fixed for trunk by now, I couldn't find any duplicating bug though. Not confirming since it works for me on current trunk. 
I reproduced the problem with the latest version of Thunderbird (2.0.0.14, Windows/20080421).

I also tested this on Linux (2.0.0.14, 20080505), and the behavior is slightly different: the emoticons are completely missing in the generated PostScript code, and after opening the emoticon drop-down menu in the composition window they appear (cropped and slightly bigger than required, but they're there).
On the same machines where you see this for the current releases, can you reproduce it with the TB 3.0 Alpha 1 (Shredder) or trunk nightly versions?

http://www.mozillamessaging.com/en-US/thunderbird/3.0a1/releasenotes/
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
I just tried with Shredder/3.0a3 (sorry for the long delay in answering), the bug seems to be still around. Attachment with example will follow.
Here is an example of the bug in Shredder/3.0a3 (screenshot from print to PS file).
Thanks for reporting back. I'm still unable to reproduce this on WinXP SP2 using nightly trunk builds though. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/200811{17,20} Shredder/3.0b1pre prints emoticons correctly even without opening the smiley menu in the composition window first. Tried in both plain-text and HTML modes.

Your reference to the PostScript code in comment #6 and actually already in comment #3 made me thinking. Thus, I printed into a file using the Generic PostScript driver on Windows, but with the same result, all prints fine.

I'll leave this unconfirmed for somebody else to reproduce. This may be happening with specific conditions only. This may be some underlying memory allocation issue, if it's still present Apparently it is), but that's hard
to guess.
I'm wondering if the bug is still the same as in Thunderbird/2.0.0.x, as there is no black square with strange contents printed, but an uncentered emoticon instead, and opening the emoticons menu in the HTML compose window doesn't change anything to the result. I still have to try with the nightly trunk builds.
Ok, I confirm: the bug is NOT there in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081120 Shredder/3.0b1pre. The emoticons seem to be printed correctly (did 2-3 tests with different mails and emoticons).
per comment #9

I also can confirm as WFM here on 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090618 Lightning/1.0pre Shredder/3.0b3pre ID:20090618031425
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: