585528 - Firefox did not render the SVG file correctly

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Sharuzzaman Ahmat Raslan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

I'm viewing the sunflower model in SVG file from Wikipedia. Upon opening the URL, the rendering is not correct, compared to the reference PNG image.

I believe something is wrong with the SVG rendering engine.

PNG reference: http://en.wikipedia.org/wiki/File:SunflowerModel.svg
SVG file: http://upload.wikimedia.org/wikipedia/commons/a/ad/SunflowerModel.svg

Reproducible: Always

Steps to Reproduce:
1. Open URL for SVG file
2. SVG file renders incorrectly
3.
Actual Results:  
SVG file incorrectly rendered

Expected Results:  
The SVG file should be rendered like the reference PNG

Comment 1

[Robert Longson [:longsonr]]

Spaces are not allowed in length attributes per http://www.w3.org/TR/SVG/types.html#Length.

For instance...

   <ellipse cx="     280" cy="     220" rx="5" ry="5" />

Both the cx and cy values are invalid. We report this in the Error Console if you care to look.

Comment 2

[Sharuzzaman Ahmat Raslan]

Robert,

W3C validator and validator.nu reported the file as valid.

I'm sorry I'm not that knowledgeable about specification, but I don't see from the link that you provide, saying that space is now allowed in length attribute.

The XML specification mention that parser must normalize attribute value. See http://www.w3.org/TR/2006/REC-xml11-20060816/#AVNormalize

Perl Rasterize.pm module is performing attribute value normalization by default. From their info page:

White Space Handling

The XML specification (http://www.w3.org/TR/2006/REC-xml11-20060816/#AVNormalize) states that an attribute value unless it is of the type CDATA shall be normalized such that leading and trailing white space is removed and internal white space is flattened to single space characters. XML entities can complicate this normalization, see the specification for details.

If the SVG tree to be rasterized by SVG::Rasterize comes out of an parsed XML document then the parser should have performed this normalization already. However, the tree might also be constructed directly using the SVG module. In order to prevent SVG::Rasterization from choking on an attribute like stroke-width="2pt " it performs by default an additional normalization run:

  $value =~ s/^$WSP*//;
  $value =~ s/$WSP*$//;
  $value =~ s/$WSP+/ /g;

where

  $WSP = qr/[\x{20}\x{9}\x{D}\x{A}]/;  # space, tab, CR, LF

To prevent this normalization, you can set the normalize_attributes attribute to a false value.

Link: http://search.cpan.org/~lgehlen/SVG-Rasterize-0.002000/lib/SVG/Rasterize.pm#ADVANCED_TOPICS

Comment 3

[Robert Longson [:longsonr]]

Then the w3c validator has an error. Please report that to w3c.

Someone translated the specification into english in bug 404089 comment 4 if you're having trouble reading it.

Comment 4

[Robert Longson [:longsonr]]

Although you're claiming a bug in the XML parser according to http://www.w3.org/TR/2006/REC-xml11-20060816/#AVNormalize so I'll redirect this to the parser and those folks can consider it.

Comment 5

[Robert Longson [:longsonr]]

All attributes for which no declaration has been read SHOULD be treated by a non-validating processor as if declared CDATA.

FWIW... We're a non-validating processor.

Comment 6

[Peter Van der Beken [:peterv]]

As Robert points out, we're a non-validating parser so afaict we shouldn't normalize. Reopen if we're mistaken.

Comment 7

[Sharuzzaman Ahmat Raslan]

If Firefox is non-validating parser, why it must be so strict with the input?

I believe validating parser should be strict because you are trying to validate against a standardized rules, but non-validating parser should be relax and tries as possible to get the correct output.

Shouldn't it be like that?

Comment 8

[Robert Longson [:longsonr]]

The SVG specification is strict about the input that is valid. You could raise it with w3c whether it should be less strict with a non-validating parser.