36869 - prints a _. before slashdot article heading

Status: VERIFIED DUPLICATE of bug 37589

(Core :: Graphics: ImageLib, defect, P3)

Description

[Nik Mani]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
BuildID:    2000041805

Every news article on slashdot shows a _. before the actual article heading. 
This does not show up in other browsers.

Reproducible: Always
Steps to Reproduce:
1. Launch and browse over to Slashdot @ www.slashdot.org
2.
3.

Actual Results:  Article Heading shows the charecters that should not be 
printed.
"_.Microsoft deemed a monopoly..."

Expected Results:  "Microsoft deemed a monopoly..."

Seems to be a Rendering issue.

Comment 1

[Kevin Hecht]

I don't think I'm seeing this, but maybe I'm doing the right thing to repro it.

In build 2000042010 I went to slashdot.org, and I don't see any unwanted 
underscore characters before article headlines or in the title bar. I also 
clicked on several articles (the "Read More..." links) and I still didn't see 
underscores.

Please either post more exact instructions to reproduce or attach a screenshot.

Comment 2

[Nik Mani]

Attachment: Screen capture of the slashdot page showing the problem

Comment 3

[Nik Mani]

Attachment: Reverified same build on different PC celeron 333/ ATI video

Comment 4

[R.K.Aa.]

I don't see this problem on Linux, but judging from attached screenshot, i don't
think the problem isn't with the article headers as such. It can look like the
alt-text for the corner gif is displaying underneath the gif in two different
shades of blue. The alt-text is only given as a ""

<TR><TD valign=top bgcolor="#006666"><IMG
src="http://images.slashdot.org/slc.gif" width=13 height=16 alt="" align=top>

There's been quite a few issues with images alt-tags displaying instead of
images.

[e-mail]: Can that be correct...that it's the "" you see below the image?
(If you use font-smooting, turn that off before you make a screenshot, then 
enlarge the area to check it.)

Comment 5

[R.K.Aa.]

argh - double negative: i don't think the problem IS with the article
heading...etc.

Comment 6

[Nik Mani]

More info on the bug. On a AMD K6 450 with a SIS video controller OS win98 the
problem is not valid. (an IBM PC with an onboard video controller)
I am not sure what you mean by "" in the screen capture. Isnt font smoothing
an OS function ? So far the OS's and video i have checked this on are:
NT4 SP4 PIII 500 laptop with ATI video (Problem exists)
W98 Celeron 333 Desktop with ATI video (Problem exists)
W98 AMD K6 450 Desktop SIS Video (Problem does not exist)
NT4 SP4 PIII 450 desktop sith S3 Trio3D video (Problem exixts)

Comment 7

[R.K.Aa.]

in W96/OSR2 font-smooting was part of +Pack and could be turned off/on.
It's not an OS thing as such, more a font-thing. Anways - this bug has been
reported earlyer also so it's a duplicate but i'm not sure of what yet.
Once that is clear it will be relevant to bring your observations into that bug.
Nice digging :)
Since it can be driver dependant it makes it more likely it IS a mispainting
after all, and not a html parser-bug where the "" embracing an empty img alt=""
is visible.
Changing component to ImageLib

Possible dup of bug 16100 (where similar duplicates have been filed)
(The phenomena at slashdot is later also reported in bug 37589)

Comment 8

[R.K.Aa.]

Changing status to new for now, bug is real enough.

Comment 9

[R.K.Aa.]

Changing status to new for now, bug is real enough.

Comment 10

[Nik Mani]

Attachment: Does appear to change on new browser windows

Comment 11

[Nik Mani]

Attachment: started a new browser for the same page image changed

Comment 12

[Nik Mani]

Font smoothing turned OFF and did as 37589 suggested and Viola!! the problem 
does change. hopefully these screen captures are better.

Comment 13

[rickg]

Don -- I can't quite make sense of this bug report, but please look into the 
printing issues.

Comment 14

[Nik Mani]

Trying to make more sense. Screen captures dated 05/01/00 08:37 and 08:39 were
taken in an attempt to prove or disprove the problem description in BUG#37589
which lists a similar problem, and seemed to point towards the imglib. The 2
captures were taken one after the other in 2 different browser windows and as
described in #37589 the charecters being printed do change. Hope this clarifys
the non-cohearent message typed earlier.

Comment 15

[dcone (gone)]

I think this is a duplicate.

*** This bug has been marked as a duplicate of 37589 ***

Comment 16

[Scott Brodmerkle]

Verified dupe.