Closed Bug 620793 Opened 9 years ago Closed 4 years ago

Starbucks logo SVG file renders with "S" partially clipped

Categories

(Core :: SVG, defect)

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1063486

People

(Reporter: benjamin-schwarz, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Attachments

(5 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

I realized that in some cases, standard-compliant SVGs are rendered incorrectly.
For example some elements are cut off or missing.

Reproducible: Always

Steps to Reproduce:
1. Open http://upload.wikimedia.org/wikipedia/de/1/1e/Starbucks.svg
Actual Results:  
The "S" on the left side of the logo is cut off. This is clearly visible at the higehst zoom level.

Expected Results:  
The image should render correctly as shown here: http://upload.wikimedia.org/wikipedia/de/thumb/1/1e/Starbucks.svg/2000px-Starbucks.svg.png
I see the correct rendering over here (on Mac).  Is this a Windows-only issue?
Looks fine for me, too, on Linux.
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20101221 Firefox/4.0b9pre

Nordware: could you post a screenshot of what you're seeing?
The S of Starbucks is slightly flat on its top left side as if the letter was clipped vertically. This is a regression, 3.6.x is correct.

Daniel, Boris, do you see that? It's fairly subtle.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ah, yes -- I do see what Robert describes. (Thanks for the clarification)

Confirmed working in 3.6.x, broken in latest m-c nightly.
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
I'm not seeing it here, but if it's really subtle I might just be totally missing it or something....
I wonder if it might be something caused by jwatt's path animation rework? Applying the patch in bug 610594 doesn't help.
Yeah, I don't see anything nearly that obvious.
Attached image Comparsion
Now it should be clearly visible to everyone.
On the left side is the correct reference rendering of the "S" made using GIMP, on the right side you can clearly see the cut-off left edge.
2010-04-27-04-mozilla-central Bad
2010-04-26-04-mozilla-central OK

regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-04-26+&enddate=2010-04-27+02%3A39

So it's most likely the cairo update as there are no SVG fixes in the range.
Keywords: testcase
This bug seems to be fixed in both Firefox 4.0 and the current Aurora build (Mozilla/5.0 (Windows NT 6.1; rv:5.0a2) Gecko/20110501 Firefox/5.0a2).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
It's just as broken as it was on 4.0 and on Trunk for me. That's as expected as trunk hasn't had a cairo update and 4.0 hasn't really had any updates at all.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This bug seems to be fixed in the current Aurora builds. Please can someone confirm this, so we can close it?
I still see the cropped "S" in the reduced testcase, using yesterday's nightly build.  So I think this isn't fixed, sadly.
Mozilla/5.0 (X11; Linux i686; rv:9.0a1) Gecko/20110820 Firefox/9.0a1
(In reply to Daniel Holbert [:dholbert] from comment #16)
> I still see the cropped "S" in the reduced testcase, using yesterday's
> nightly build.  So I think this isn't fixed, sadly.
> Mozilla/5.0 (X11; Linux i686; rv:9.0a1) Gecko/20110820 Firefox/9.0a1

Ok, so this seems to only appear in nightly builds. At least this information might help the developers...
(In reply to Nordware from comment #17)
> Ok, so this seems to only appear in nightly builds.

Rather, I think it probably just doesn't reproduce on your system (perhaps due to different fonts or something).  I don't think it generally renders differently in Nightly vs. Aurora.
(In reply to Daniel Holbert [:dholbert] from comment #18)
> (In reply to Nordware from comment #17)
> > Ok, so this seems to only appear in nightly builds.
> 
> Rather, I think it probably just doesn't reproduce on your system (perhaps
> due to different fonts or something).  I don't think it generally renders
> differently in Nightly vs. Aurora.

It's the same system, where i opened the bug from. There was nothing changed since i reported the bug. But i will test it again by running the latest nightly instead of Aurora and report the results here...
Ah -- sorry, I hadn't looked at this bug for a while, and I'd forgotten that you were the original reporter. :)

In that case: If it turns out that you can't reproduce the bug anymore on nightly/aurora but you still can reproduce it with old builds, it might be interesting to track down the nightly range that it became fixed on your system, if you get a chance.

(I verified that I can still reproduce on Aurora, fwiw)
Ok, i tested it again on the current release build (Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0), the current beta (Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0), the latest Aurora (Mozilla/5.0 (Windows NT 6.1; rv:8.0a2) Gecko/20110822 Firefox/8.0a2) and the latest Nightly (Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110822 Firefox/9.0a1).
The bug doesn't appear on any of them. Is it still present in the equivalent Linux builds?
>  Is it still present in the equivalent Linux builds?

Yup, bug still present. (I've checked aurora & nightly, and I have no reason to believe it fixed itself & re-broke itself between Firefox 4 and those.)

So -- it seems likely that something changed on Nordware's system to make the bug no longer reproduce there in any builds, which is interesting, but probably not worth spending too many comments investigating. :)  For now, take my word for it that it's still broken on Linux.
Attached image minimized testcase (obsolete) —
I managed to create a minimized testcase. Two red shapes with a black outline in the background and two identical green shapes (without outline) on top of them. The black outline should be solid all the way and no red parts should be visible.

Slight changes may prevent the bug from triggering, e.g.:
- removing the small "cap" or moving it slightly downwards
- moving the two shapes into their own path elements
- rearranging the path segments of the larger shape
That's how a recent trunk build renders the minimized testcase on FreeBSD 9.1RC3.
Attached image minimized testcase (obsolete) —
This testcase is even further minimized.

Again a green shape on top of a red one. There should be no red visible.
Attachment #680398 - Attachment is obsolete: true
Screenshot updated to current (minimized) testcase on current trunk build.
Attachment #680399 - Attachment is obsolete: true
I haven't been able to reproduce this bug in quite a while.
But then again, the FreeBSD ports got a cairo update (1.10.2 to 1.12.16) a few months ago.
Daniel, are you still able to reproduce it on your system?
I can still reproduce, using current Nightly 38 & longsonr's "slightly reduced testcase", attachment 500793 [details]. The capital "S" is still clipped.

(I can *not* reproduce with another_loco's "minimized testcase", attachment 8351584 [details] -- that renders with no red for me.  So, that testcase seems to not be fully testing the same issue that the original "Starbucks" testcase hits, at least on my system.)

Also: --> Updating bug summary to be more specific about the problem.
Summary: Some SVGs rendered incorrectly → Starbucks logo SVG file renders with "S" partially clipped
Attached image minimized testcase
Ooops, my bad. And yes, the slightly reduced testcase still exhibits the bug on my machine. This new testcase contains just the S and enough of the left star to trigger the bug.
(The S should be further simplified, but it's getting late... ;-) )
Attachment #8351584 - Attachment is obsolete: true
Attachment #8351585 - Attachment is obsolete: true
Attached image extended testcase
It looks like the code that sets the path's bounding box gets confused.
In this case it leads to the clipping of the path's filling.
I'm not sure, but I think I've seen cases where the outline was affected, too.
This was fixed by the patch for bug 1063486 (confirmed with mozregression).
Status: REOPENED → RESOLVED
Closed: 9 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1063486
You need to log in before you can comment on or make changes to this bug.