Closed Bug 349907 Opened 18 years ago Closed 16 years ago

Artifacts in large brackets with antialiasing

Categories

(Core :: MathML, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: karlt)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060501 Epiphany/2.14
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060501 Epiphany/2.14

Seems to me that the MathML layout engine when rendering long strokes of stretched brackets out of smaller pieces, makes them slightly overlap eachother (one pixel?).  This makes a jagged stroke at certain sizes that the stroke is not hinted to full pixel boundaries and so has an antialiased gray pixel on the side.

Attaching screenshot.

Reproducible: Always
Right -- the alternative produces "holes". Which of the two is the lesser evil? I think the gray, which is why I made them to overlap -- see bug 307157.

Maybe a case for an #ifdef to pick one or the other depending on the back-end?
Status: UNCONFIRMED → NEW
Ever confirmed: true
But curved endpoints is a different issue.  I'm not sure with butt ends you get holes on the screen.

I've been experiencing this problem on and off on different systems, as I work on Arabic.  We are getting the jagged effect because our fonts have overlaps.  Keith Packard tells me that I won't get holes if the fonts didn't have the overlap (though that may only be true for glyphs drawn in a single Xft operation).  And if you think about it the only hope for fixing this is when you don't overlap.  So, maybe you can remove the overlap for characters with the butt ending and if any holes show up, we can track it dowsn.
This is what Keith Packard says about it:

keithp: behda1: yes, you should 'pre-add' the glyphs together before compositing to the destination
keithp: behda1: Render does this if you send all of the glyphs in a single request with an intermediate format specified
keithp: behda1: alternatively, you can create a temporary alpha image the size of the output, Add the glyphs to that, then Over to the dest
keithp: behda1: note that Xft doesn't attempt to deal with 'really long' strings; it just breaks them up and so you can expect a seam in those cases.
>But curved endpoints is a different issue.  I'm not sure with butt ends you get
>holes on the screen.

For an example of an ealier rendering (when the overlap wasn't added yet), see the .png below (from the link you actually gave in bug 349904)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=mathml)

http://www.math.ist.utl.pt/~jmatos/CapturaEcra-13.png
Depends on: 427666
Assignee: rbs → mozbugz
QA Contact: ian → mathml
These artifacts are also visible on Windows particularly when ClearType is enabled.

Attachment 315709 [details] [diff] resolves these issues by clipping off the outside pixel of the glyphs at joins so that there is a solid edge to join.  This works well on Linux and Windows.

I just need to find someone with a Mac to test whether it works well with the anti-aliasing filters on that platform.  Builds are available here:

https://build.mozilla.org/tryserver-builds/2008-04-15_02:07-ktomlinson@mozilla.com-1208250392/
OS: Linux → All
(In reply to comment #6)
> I just need to find someone with a Mac to test whether it works well with the
> anti-aliasing filters on that platform.

Yes, works well there too.  Thanks, cairo for being consistent.
Fixed in bug 427666.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.