Donat Polygons in Mozilla SVG

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: Ruth Lang, Assigned: tor)

Tracking

1.8 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051025 Firefox/1.5

Attached a svg file which shows that donat polygons are not displayed correctly. Please have a look at the same file with the Internet Explorer and the Adobe SVG Viewer. There the yellow polygon covers the white "donut"
Thank you for your help
Ruth

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<svg  id="map" x="0" y="0" width="1000" height="888"  viewBox="234.003 147.272 356.055 316.428" preserveAspectRatio="xMinYMin" xmlns="http://www.w3.org/2000/svg"  version="1.1" baseProfile="full">
<path id="th0rec55" fill="blue" d="M463.013 281.513l3.383 -1.354l3.617 6.354l-0.500 6.500l-2.000 5.500l-4.000 12.500l-0.500 1.000l-2.000 5.500l-1.000 4.000l-1.000 3.500l-0.500 5.000l0.500 6.000l2.000 5.500l5.000 4.500l6.500 4.000l8.500 6.500l10.000 5.000l7.000 4.500l4.000 3.000l2.500 1.500l5.500 3.000h5.000l4.500 -1.500l3.000 -2.500l3.500 -4.000l6.500 2.000l-18.000 23.500l-2.000 -3.500l-3.000 -6.000l-5.500 -4.000l-6.500 -4.500l-6.000 -4.000l-1.390 -1.057l-14.054 -8.362l-10.572 -7.058l-19.945 -13.316l-20.353 -8.362l-9.273 -2.406l-36.575 -17.239l-0.328 -0.223l-35.713 -17.052l-14.797 -5.425l-2.246 -0.658l-5.238 -1.535l-3.167 -0.273l-4.763 0.966l-10.147 7.560l-15.231 16.045l-3.421 3.193l0.271 0.125l-1.254 1.298l-3.808 3.942
l-15.049 15.600l-1.005 0.341l-5.910 5.503l1.968 -3.607l-2.674 -1.337l14.795 -14.499l8.721 -9.180l4.088 -4.303l11.123 -12.471l4.361 -3.894l5.077 -4.533l6.067 -4.045l6.404 -1.348l5.056 -0.337l6.067 1.685l16.815 6.540l3.100 1.722l7.500 3.000l31.259 17.104l20.885 10.070l13.856 4.826l8.000 1.000l8.000 -2.500l6.000 -4.500l5.000 -7.000l9.000 -11.500l7.500 -15.500 z
m-3.125 25.874l-4.935 7.403l-6.267 7.585l-4.947 4.617l-8.245 3.298l5.277 1.979l6.926 3.298l5.280 3.443l-0.464 -6.497l0.500 -6.000l1.500 -7.500l4.500 -9.500 z" />
<path id="th0rec63" style="fill:rgb(255,215,0)" d="M459.888 307.387l-0.875 2.126l-4.500 9.500l-1.500 7.500l-0.500 6.000l0.464 6.497l-5.280 -3.443l-6.926 -3.298l-5.277 -1.979l8.245 -3.298l4.947 -4.617l6.267 -7.585 z" />
</svg>


Reproducible: Always

Comment 1

13 years ago
->Core:SVG
Assignee: nobody → general
Component: General → SVG
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch

Comment 3

13 years ago
The render in netscape looks the same as Firefox. Do you have a png of the
correct render?

Comment 4

13 years ago
(In reply to comment #3)
> The render in netscape looks the same as Firefox. Do you have a png of the
> correct render?

That should be INKSCAPE http://www.inkscape.org/ ! Inkscape! I don't use
Netscape, sorry.
Ben, if you look at Ruth's testcase with latest branch (try RC1) you'll see what's wrong.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

13 years ago
(In reply to comment #5)
> Ben, if you look at Ruth's testcase with latest branch (try RC1) you'll see
> what's wrong.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051104 Firefox/1.6a1

Fair do's I am using a trunk build only a few minutes old. Are you suggesting that
that trunk is OK, but the branch is not ...

Comment 7

13 years ago
That's it. The yellow segment is about 15 pixels to the left and above where 
it should be.
Yup. They've diverged considerably, and in the case of SVG, the branch uses cairo whereas the trunk still uses GDI+. Matching your build with the Version field of bugs is much more important than being up to date to the minute. ;-)
(In reply to comment #8)
> Yup. They've diverged considerably, and in the case of SVG, the branch uses
> cairo whereas the trunk still uses GDI+.

Is that still true, given bug 310957? He's also using a Mac build, so that shouldn't matter, right?
(Assignee)

Comment 10

13 years ago
Created attachment 201856 [details] [diff] [review]
nsSVGCairoPathBuilder::ClosePath wasn't returning new point
Assignee: general → tor
Status: NEW → ASSIGNED
Attachment #201856 - Flags: review?(scootermorris)
(In reply to comment #9)
> (In reply to comment #8)
> > Yup. They've diverged considerably, and in the case of SVG, the branch uses
> > cairo whereas the trunk still uses GDI+.
> 
> Is that still true, given bug 310957? He's also using a Mac build, so that
> shouldn't matter, right?

To be clearer about the state of GDI+ vs cairo: cairo is the default on all platforms, but some of the w32 trunk tinderbox still build with GDI+ because their version of cairo hasn't been updated yet. Anyway, my point (badly made I admit) was that trunk and branch are different, and testing should be against the bug's Version. I didn't mean to say cairo was or wasn't the source, even though that seems to be what tor has found. Sorry about that.

Updated

13 years ago
Attachment #201856 - Flags: review?(scootermorris) → review+
(Assignee)

Comment 12

13 years ago
Checked in on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.