Firefox corrupts svg files !
I send this message here because they concern settings files created for Inkscape and I think everybody concerned by svg creation could be concerned.
Some time ago I placed some svg filters files on OpenClipart and more recently I heard from users that they didn't work despite all my tests were positive. Yesterday I discovered that following the way you take to download them they work or not. The problem seems to be specific to Firefox and doesn't occur with other browsers (tried with Safari, Opera and Chrome).
Here are the address of the two files :
The first one is an Inkscape template which activates filters for background images or objects :
http://www.openclipart.org/detail/92749
This second one contains color filters decicated to work on background object or images (place any shape on top of a picture and apply the filters to this shape) :
http://www.openclipart.org/detail/92977
Here is the problem :
- When you click on the "Download SVG" button on the OpenClipart page it opens the svg in Firefox. Then, if you save this SVG file displayed in Firefox and try to work with it in Inkscape it doesn't work because Firefox changed something in the file.
- If you right click on the "Download SVG" button and do "Save target as", then the file download unchanged on your disk and all works as expected.
Could somebody send the bug to Firefox ?
Thanks for your attention,
ivan
[ resending to the list this time ]
On 11/12/10 12:03, Ivan Louette wrote:
Some time ago I placed some svg filters files on OpenClipart and more recently I heard from users that they didn't work despite all my tests were positive. Yesterday I discovered that following the way you take to download them they work or not. The problem seems to be specific to Firefox and doesn't occur with other browsers (tried with Safari, Opera and Chrome).
Here are the address of the two files :
The first one is an Inkscape template which activates filters for background images or objects :
http://www.openclipart.org/detail/92749
This second one contains color filters decicated to work on background object or images (place any shape on top of a picture and apply the filters to this shape) :
http://www.openclipart.org/detail/92977
Here is the problem :
- When you click on the "Download SVG" button on the OpenClipartpage it opens the svg in Firefox. Then, if you save this SVG file displayed in Firefox and try to work with it in Inkscape it doesn't work because Firefox changed something in the file.
In my experience (Firefox 3.6 on OS X 10.5.8) Firefox only modifies the content of SVG files (e.g. replacing hex color definitions by 'rgb()' values) if you save the SVG as 'Web page (complete)' instead of 'Web page (SVG only)'. Don't forget to check when using 'File > Save Page As…', because Inkscape remembers the last used setting (thus overriding the correct mime-type sent by the server by respecting the user's choice).
AFAICT, if the file type in the 'Save Page As…' hasn't been changed manually, Firefox uses the correct file type for SVG files and does *not* modifiy the content in any way.
- If you right click on the "Download SVG" button and do "Savetarget as", then the file download unchanged on your disk and all works as expected.
Yes, because AFAIU the correct file type (as declared or delivered by the web server) is used automatically.
Could somebody send the bug to Firefox ?
Not sure this is really a bug in Firefox, maybe a usability issue?
<off-topic> BTW - as commented in http://www.openclipart.org/detail/90775 some of your filter files don't 'open' in Inkscape (nor in Firefox) because they are invalid SVG (no xlink namespace), though apparently this doesn't prevent them from being parsed for the 'Filters' menu.
affects afaict: http://www.openclipart.org/detail/90775 http://www.openclipart.org/detail/92899 http://www.openclipart.org/detail/95053 </off-topic>
hth, ~suv
Thanks for your reply !
As you say probably not a bug but to my sense certainly an usability issue.
Thanks also about your off topic comment. But I don't know how I could precise an xlink namespace in FeImage filters when it must be precised by the person who uses the filter. Of course this isn't correct for displaying in a browser but this file is done to be parsed by Inkscape and as you said it works (However I don't have problems to open it in 0.48.01 and 0.48 devel 9936 on kubuntu 10.04).
Thanks again, ivan
________________________________ De : ~suv <suv-sf@...58...> À : Ivan Louette <ivan_louette@...48...> Cc : Inkscape-devel@lists.sourceforge.net; clipart@...626... Envoyé le : Sam 11 décembre 2010, 12h 30min 21s Objet : Re: [Inkscape-devel] Firefox corrupts svg files !
[ resending to the list this time ]
On 11/12/10 12:03, Ivan Louette wrote:
Some time ago I placed some svg filters files on OpenClipart and more recently I heard from users that they didn't work despite all my tests were positive. Yesterday I discovered that following the way you take to download them they work or not. The problem seems to be specific to Firefox and doesn't occur with other browsers (tried with Safari, Opera and Chrome).
Here are the address of the two files :
The first one is an Inkscape template which activates filters for background images or objects :
http://www.openclipart.org/detail/92749
This second one contains color filters decicated to work on background object or images (place any shape on top of a picture and apply the filters to this shape) :
http://www.openclipart.org/detail/92977
Here is the problem :
- When you click on the "Download SVG" button on the OpenClipartpage it opens the svg in Firefox. Then, if you save this SVG file displayed in Firefox and try to work with it in Inkscape it doesn't work because Firefox changed something in the file.
In my experience (Firefox 3.6 on OS X 10.5.8) Firefox only modifies the content of SVG files (e.g. replacing hex color definitions by 'rgb()' values) if you save the SVG as 'Web page (complete)' instead of 'Web page (SVG only)'. Don't forget to check when using 'File > Save Page As…', because Inkscape remembers the last used setting (thus overriding the correct mime-type sent by the server by respecting the user's choice).
AFAICT, if the file type in the 'Save Page As…' hasn't been changed manually, Firefox uses the correct file type for SVG files and does *not* modifiy the content in any way.
- If you right click on the "Download SVG" button and do "Savetarget as", then the file download unchanged on your disk and all works as expected.
Yes, because AFAIU the correct file type (as declared or delivered by the web server) is used automatically.
Could somebody send the bug to Firefox ?
Not sure this is really a bug in Firefox, maybe a usability issue?
<off-topic> BTW - as commented in http://www.openclipart.org/detail/90775 some of your filter files don't 'open' in Inkscape (nor in Firefox) because they are invalid SVG (no xlink namespace), though apparently this doesn't prevent them from being parsed for the 'Filters' menu.
affects afaict: http://www.openclipart.org/detail/90775 http://www.openclipart.org/detail/92899 http://www.openclipart.org/detail/95053 </off-topic>
hth, ~suv
On 11/12/10 12:49, Ivan Louette wrote:
Thanks also about your off topic comment. But I don't know how I could precise an xlink namespace in FeImage filters when it must be precised by the person who uses the filter. Of course this isn't correct for displaying in a browser but this file is done to be parsed by Inkscape and as you said it works
It seems that you manually pasted the new filter effects into an old filter.svg (created with ancient 'inkscape:version="0.46+devel r20644 custom"')? Otherwise Inkscape would have added the namespace declaration itself, as it normally does as soon as internal or external resources are linked via 'xlink:href'.
AFAIU all it would require is adding xmlns:xlink="http://www.w3.org/1999/xlink" to the top-level <svg> element of the enhanced or experimental 'filters.svg', along with the other already existing attributes. But maybe some SVG experts can confirm this?
(However I don't have problems to open it in 0.48.01 and 0.48 devel 9936 on kubuntu 10.04).
Yes, sorry - I was not precise: while it fails to open in Firefox, it does open in Inkscape (0.48 and trunk), but with tons of error messages on the console like this:
filters7-2010-10-13.svg:193: namespace error : Namespace prefix xlink for href on feImage is not defined
<feImage id="feImage3446" xlink:href="" result="result3" /> ^
another <off-topic>: There is a second issue with your filters alternate 8 and 9 I have experienced: As far as I could track it down, in the file there is a new filter effect (inkscape:label="Old postcard -NEW-") using ',' as decimal separators in the 'tableValues' for the 'feComponentTransfer' primitive.
<filter id="f174" inkscape:label="Old postcard -NEW-" x="0" y="0" width="1" height="1" inkscape:menu="Image paint and draw" inkscape:menu-tooltip="Slightly posterize and draw edges like on old printed postcards" color-interpolation-filters="sRGB"> <feFlood flood-color="rgb(255,204,0)" flood-opacity="0.1" result="result1" /> <feBlend in2="SourceGraphic" blend="normal" mode="darken" result="result6" /> <feComposite result="result8" operator="arithmetic" k2="1" /> <feColorMatrix result="result5" values="0" type="hueRotate" in="result8" /> <feConvolveMatrix result="result1" order="3 3" kernelMatrix="0 -1 0 -1 5.05 -1 0 -1 0 " divisor="1" in="result5" targetX="1" targetY="1" /> <feGaussianBlur result="result2" stdDeviation="2" in="result1" /> <feComponentTransfer result="result4" in="result2"> <feFuncR type="table" tableValues="0 0 0,2 0,2 0,4 0,4 0,6 0,6 0,8 0,8 1 1 1" /> <feFuncG type="table" tableValues="0 0 0,2 0,2 0,4 0,4 0,6 0,6 0,8 0,8 1 1 1" /> <feFuncB type="table" tableValues="0 0 0,2 0,2 0,4 0,4 0,6 0,6 0,8 0,8 1 1 1" /> </feComponentTransfer> <feBlend in2="result1" result="result3" mode="darken" in="result4" /> <feColorMatrix type="saturate" values="1" result="result7" /> <feComposite in2="SourceGraphic" operator="in" result="fbSourceGraphic" /> </filter>
This causes Inkscape launched with (e.g.) LANG="en_US.UTF-8" (decimal separator '.') to freeze when trying to parse the filter definitions.
After manually editing the SVG file (adding the xlink namespace declaration and replacing the ',' decimal separator with '.', the file opens without issues in Inkscape 0.48 and 0.48+devel (current).
Seems related to Bug #586059 “Period not accepted in filter matrices UI (FR locale and maybe others)”: https://bugs.launchpad.net/inkscape/+bug/586059
For shared filters.svg files it might be better to not use a localized Inkscape version (to be save) or verify that the decimal separators within the file are consistent.
Maybe one of the filter experts can take a look at this? </off-topic>
~suv
2010/12/11 ~suv <suv-sf@...58...>:
On 11/12/10 12:49, Ivan Louette wrote: AFAIU all it would require is adding xmlns:xlink="http://www.w3.org/1999/xlink" to the top-level <svg> element of the enhanced or experimental 'filters.svg', along with the other already existing attributes. But maybe some SVG experts can confirm this?
Yes, this should fix it. The XLink namespace is always the same. Ivan's comment about the user of the filter changing the XLink namespace is a bit nonsensical to be honest. The namespace is just a formal requirement of the XML parser, not some user-definable value like the target of a link.
Seems related to Bug #586059 “Period not accepted in filter matrices UI (FR locale and maybe others)”: https://bugs.launchpad.net/inkscape/+bug/586059
For shared filters.svg files it might be better to not use a localized Inkscape version (to be save) or verify that the decimal separators within the file are consistent.
This is a different bug. 586059 is about the period not being accepted in the UI, while here the bug is about localized values being written to the SVG - a much more severe thing, because it results in non-conformant documents. I have a fix, but it appears that the recent GSoC merge broke the open dialog, so I can't verify it.
Regards, Krzysztof
W dniu 12 grudnia 2010 14:36 użytkownik Krzysztof Kosiński <tweenk.pl@...400...> napisał:
This is a different bug. 586059 is about the period not being accepted in the UI, while here the bug is about localized values being written to the SVG - a much more severe thing, because it results in non-conformant documents. I have a fix, but it appears that the recent GSoC merge broke the open dialog, so I can't verify it.
Fixed in 9948, I discovered that opening files from the command line works.
Regards, Krzysztof
Thanks Krzysztof,
Of course my comment about XLink namespace was wrong. I was thinking at keeping "href" empty inside the filter like that : xlink:href="" which is the result of removing the image reference from inside the Filters editor. If that's not correct SVG which alternative do you propose or what is the right way ?
About the "," problem, this mistake was only caused by my distraction while entering manually Component transfer values into the XML editor (that's because this primitive works perfectly and gives fantastic results but has no UI at the moment in the Filters editor).
ivan
________________________________ De : Krzysztof Kosiński <tweenk.pl@...400...> À : ~suv <suv-sf@...58...> Cc : Ivan Louette <ivan_louette@...48...>; Inkscape-devel@...1239....net Envoyé le : Dim 12 décembre 2010, 14h 36min 53s Objet : Re: [Inkscape-devel] Re : Firefox corrupts svg files !
2010/12/11 ~suv <suv-sf@...58...>:
On 11/12/10 12:49, Ivan Louette wrote: AFAIU all it would require is adding xmlns:xlink="http://www.w3.org/1999/xlink" to the top-level <svg> element of the enhanced or experimental 'filters.svg', along with the other already existing attributes. But maybe some SVG experts can confirm this?
Yes, this should fix it. The XLink namespace is always the same. Ivan's comment about the user of the filter changing the XLink namespace is a bit nonsensical to be honest. The namespace is just a formal requirement of the XML parser, not some user-definable value like the target of a link.
Seems related to Bug #586059 “Period not accepted in filter matrices UI (FR locale and maybe others)”: https://bugs.launchpad.net/inkscape/+bug/586059
For shared filters.svg files it might be better to not use a localized Inkscape version (to be save) or verify that the decimal separators within the file are consistent.
This is a different bug. 586059 is about the period not being accepted in the UI, while here the bug is about localized values being written to the SVG - a much more severe thing, because it results in non-conformant documents. I have a fix, but it appears that the recent GSoC merge broke the open dialog, so I can't verify it.
Regards, Krzysztof
W dniu 12 grudnia 2010 15:01 użytkownik Ivan Louette <ivan_louette@...48...> napisał:
About the "," problem, this mistake was only caused by my distraction while entering manually Component transfer values into the XML editor (that's because this primitive works perfectly and gives fantastic results but has no UI at the moment in the Filters editor).
The filter editing code was storing localized floating point values in the SVG. I changed it to use g_ascii_strtod and Inkscape::SVGOStringStream instead of g_strtod and std::ostringstream. I think that problem could have been legitimate.
Regards, Krzysztof
On 11/12/10 12:30, ~suv wrote:
On 11/12/10 12:03, Ivan Louette wrote:
Some time ago I placed some svg filters files on OpenClipart and more recently I heard from users that they didn't work despite all my tests were positive. Yesterday I discovered that following the way you take to download them they work or not. The problem seems to be specific to Firefox and doesn't occur with other browsers (tried with Safari, Opera and Chrome).
This second one contains color filters decicated to work on background object or images (place any shape on top of a picture and apply the filters to this shape) :
When saving this example as 'Web Page, SVG only' and as 'Web Page, complete', the relevant change here seems to be:
$ diff -u 1288285193-SVG.svg 1288285193-WebPage.svg
-<g inkscape:label="Calque 1" inkscape:groupmode="layer" id="layer1" transform="translate(0,-308.2677)" style="enable-background:new" /> -</svg> +<g inkscape:label="Calque 1" inkscape:groupmode="layer" id="layer1" transform="translate(0, -308.268)" style=""/> +</svg> \ No newline at end of file
i.e. saved as web page, Firefox removes the 'enable-background:new' property.
The default in Firefox 3.6 (at least on OS X) is to save it correctly as 'Web Page, SVG only'. A different file type (like 'Web Page, complete') requires user interaction (for this file or for previous downloads).
~suv
participants (3)
-
Ivan Louette -
Krzysztof Kosiński -
~suv