Open Bug 204135 Opened 21 years ago Updated 2 years ago

List marker glyphs 'disc' and 'circle' are diamond shaped

Categories

(Core :: Layout, defect, P4)

x86
Linux
defect

Tracking

()

Future

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(9 files)

List marker glyphs 'disc' and 'circle' are diamond shaped when using certain
font sizes. This occurs at 14px and 15px but not with smaller or larger sizes.

Bug occurs with the following in my Preferences:
Proportional: Sans Serif        Size: 14
Sans-serif:   adobe-helvetica-iso8859-1


Bug occurs in 2003-04-30-22 trunk Linux.
Attached file Testcase #1
Keywords: testcase
Refer to bug 152588, comment 6.
Roland did some work at some point to make these draw better... so he may know
what's up.
Dupe of bug 152588 ?

See bug 152588, comment 6, which explains that they're not characters at all,
they're hand-drawn. I think the difference must be caused by the antialiasing of
the real Unicode-codepoints, or maybe one of their Truetype hints, which make
them better circles.
Can we somehow figure-out whether they are rendered as
a) as glyphs from a specific font
  OR
b) using home-grown code within Mozilla

If we use [b] then the code in
http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsRenderingContextGTK.cpp#1110
should handle the case unless someone messed with the code that we do not use
the nsIRenderingContext::FillEllipse() codepath anymore.
They're done with FillEllipse last I checked.  See nsBulletFrame::Paint() for
details.
Boris Zbarsky wrote:
> They're done with FillEllipse last I checked.  See nsBulletFrame::Paint() for
> details.

Why does the code from
http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsRenderingContextGTK.cpp#1110
then not kick-in and handle the problem ?!
You tell me.  :)  At most sizes it most certainly does.
Attached file Testcase #2
Attached file Testcase #3
Attached patch PatchSplinter Review
Fix nsRenderingContextGTK::FillEllipse/DrawEllipse for certain sizes
A good way to compare the "before" and "after" screenshots is to load them
in separate tabs and then flip between them.
Priority: -- → P4
Target Milestone: --- → Future
*** Bug 293337 has been marked as a duplicate of this bug. ***
Assignee: layout → nobody
QA Contact: ian → layout
Severity: trivial → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: