SVG path does not close (missing fill and stroke) after horizontal movement to start point

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
4 years ago
10 months ago

People

(Reporter: Brian Marshall, Unassigned)

Tracking

35 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8498570 [details]
Testcase: SVG path that should render a "G"

An SVG path with several 'c' commands, with an 'H' command at the end to return to the starting point, isn't rendering correctly. The path doesn't close (there's a slight gap in the stroke), and the affected area isn't filled.

In the attached file, a "G" should be rendered. The bug affects the horizontal part of the letter. The scale transformation and stroke make the problem more clear, but it happens without them.

Removing the 'H 9.732' command at the end, and letting the path close itself with 'z', works around the bug. Also, it's sensitive to the exact coordinates used: adding or subtracting 0.001 from the 'H' command causes the area to be filled and the stroke to connect, although the stroke still renders strangely.

The bug happens with:
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0

It doesn't happen when viewing the SVG file with GNOME Image Viewer, or with:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0

This seems similar to bug 664383, but the test cases are different enough that I can't tell if it's the same bug. Sorry if this is a duplicate.
(Reporter)

Comment 1

4 years ago
Created attachment 8498572 [details]
Incorrect (top) and correct (bottom) renders of the testcase

Comment 2

3 years ago
My team ran into this exact issue today. We were able to verify that manually removing the 'H X.XXX z' at the end inside the Firefox Inspector fixed the issue and closed the vector. 

We are looking into figuring out what we need to do to change the SVG in the image itself, but fixing the actual bug in Firefox would be most ideal since it does not occur in other browsers.

Comment 3

3 years ago
Oh, I forgot to mention that I am seeing this on 

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
(In reply to Brian Marshall from comment #0)
> Created attachment 8498570 [details]
> Testcase: SVG path that should render a "G"
> 
> An SVG path with several 'c' commands, with an 'H' command at the end to
> return to the starting point, isn't rendering correctly. The path doesn't
> close (there's a slight gap in the stroke), and the affected area isn't
> filled.
> 
> In the attached file, a "G" should be rendered. The bug affects the
> horizontal part of the letter. The scale transformation and stroke make the
> problem more clear, but it happens without them.
> 
> Removing the 'H 9.732' command at the end, and letting the path close itself
> with 'z', works around the bug. Also, it's sensitive to the exact
> coordinates used: adding or subtracting 0.001 from the 'H' command causes
> the area to be filled and the stroke to connect, although the stroke still
> renders strangely.
> 
> The bug happens with:
> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
> Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
> 
> It doesn't happen when viewing the SVG file with GNOME Image Viewer, or with:
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
> 
> This seems similar to bug 664383, but the test cases are different enough
> that I can't tell if it's the same bug. Sorry if this is a duplicate.

I have tried to recreate the issue and it is working for me from Firefox 35-41. Is attachment the only way to recreate the issue?

David
(Reporter)

Comment 5

3 years ago
(In reply to David Burns :automatedtester from comment #4)
> I have tried to recreate the issue and it is working for me from Firefox
> 35-41. Is attachment the only way to recreate the issue?
> 
> David

I still see the bug with the attachment using Firefox 38.0 on Ubuntu 14.04. I have other Illustrator-generated SVGs that are affected by the bug, but they're pretty similar to the original attachment.

Just noticed something else: the attachment renders correctly at 170% zoom. (There's another file that renders correctly at different zoom levels instead.)
Cameron, Brian,

I have tried to recreate the issue on OSX and on Linux and can't see to do it. As SVG experts, could you have a look?
I can't reproduce this on Windows or on Firefox 38.0 on Ubuntu 14.04 even after zooming in and out.

I'm guessing it's a graphics issue so adding Bas.

Brian, would you be able to paste the output of the "Graphics" section from about:support?
Flags: needinfo?(bmarsd)
(Reporter)

Comment 8

3 years ago
(In reply to Brian Birtles (:birtles) from comment #7)
> Brian, would you be able to paste the output of the "Graphics" section from
> about:support?

Sure:

Graphics
Adapter Description	Intel Open Source Technology Center -- Mesa DRI Mobile Intel® GM45 Express Chipset
Device ID	Mesa DRI Mobile Intel® GM45 Express Chipset
Driver Version	2.1 Mesa 10.1.3
GPU Accelerated Windows	0/1 Basic
Vendor ID	Intel Open Source Technology Center
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Mobile Intel® GM45 Express Chipset
windowLayerManagerRemote	false
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0
Flags: needinfo?(bmarsd)

Comment 9

3 years ago
Here is my Graphics info as well (I see the unclosed path as well):

Adapter Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) Q45/Q43
Device ID	Mesa DRI Intel(R) Q45/Q43
Driver Version	2.1 Mesa 10.1.3
GPU Accelerated Windows	0/2 Basic
Vendor ID	Intel Open Source Technology Center
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Q45/Q43
windowLayerManagerRemote	false
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0
We're using a different backend now, is the problem gone?
(Reporter)

Comment 11

10 months ago
(In reply to Milan Sreckovic [:milan] from comment #10)
> We're using a different backend now, is the problem gone?

Looks OK here now. :) I tried it on the same laptop that had the problem before.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.