620793 - Starbucks logo SVG file renders with "S" partially clipped

Status: RESOLVED DUPLICATE of bug 1063486

(Core :: SVG, defect)

Description

[Nordware]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see the correct rendering over here (on Mac).  Is this a Windows-only issue?

Comment 2

[Daniel Holbert [:dholbert]]

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?

Comment 3

[Robert Longson [:longsonr]]

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.

Comment 4

[Daniel Holbert [:dholbert]]

Ah, yes -- I do see what Robert describes. (Thanks for the clarification)

Confirmed working in 3.6.x, broken in latest m-c nightly.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I'm not seeing it here, but if it's really subtle I might just be totally missing it or something....

Comment 6

[Robert Longson [:longsonr]]

I wonder if it might be something caused by jwatt's path animation rework? Applying the patch in bug 610594 doesn't help.

Comment 7

[Robert Longson [:longsonr]]

Attachment: just the buggy S

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, I don't see anything nearly that obvious.

Comment 9

[Robert Longson [:longsonr]]

Not path animation as http://hg.mozilla.org/mozilla-central/rev/2b612890113b is broken.

Comment 10

[Nordware]

Attachment: 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.

Comment 11

[Robert Longson [:longsonr]]

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.

Comment 12

[Robert Longson [:longsonr]]

Attachment: slightly reduced testcase

Comment 13

[Nordware]

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).

Comment 14

[Robert Longson [:longsonr]]

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.

Comment 15

[Nordware]

This bug seems to be fixed in the current Aurora builds. Please can someone confirm this, so we can close it?

Comment 16

[Daniel Holbert [:dholbert]]

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

Comment 17

[Nordware]

(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...

Comment 18

[Daniel Holbert [:dholbert]]

(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.

Comment 19

[Nordware]

(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...

Comment 20

[Daniel Holbert [:dholbert]]

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)

Comment 21

[Nordware]

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?

Comment 22

[Daniel Holbert [:dholbert]]

>  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.

Comment 23

[Marco Perez [:mpk]]

Attachment: minimized testcase

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

Comment 24

[Marco Perez [:mpk]]

Attachment: Screenshot of trunk build with minimized testcase

That's how a recent trunk build renders the minimized testcase on FreeBSD 9.1RC3.

Comment 25

[Marco Perez [:mpk]]

Attachment: minimized testcase

This testcase is even further minimized.

Again a green shape on top of a red one. There should be no red visible.

Comment 26

[Marco Perez [:mpk]]

Attachment: screenshot of Nightly with minimized testcase

Screenshot updated to current (minimized) testcase on current trunk build.

Comment 27

[Marco Perez [:mpk]]

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?

Comment 28

[Daniel Holbert [:dholbert]]

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.

Comment 29

[Marco Perez [:mpk]]

Attachment: 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... ;-) )

Comment 30

[Marco Perez [:mpk]]

Attachment: 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.

Comment 31

[Tom Klein]

This was fixed by the patch for bug 1063486 (confirmed with mozregression).

Comment 32

[Daniel Holbert [:dholbert]]

That's great! Thanks, Tom!