User Details
- User Since
- Oct 21 2017, 4:23 PM (175 w, 5 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- JoKalliauer [ Global Accounts ]
Jan 20 2021
Dear Commons community, the WMF Technical Committee (link) is currently weighing an RFC (link to this one) which is basically about changing the SVG renderer. What this means is that some SVG that currently renders correctly will no longer render correctly. But that many of the current rendering issues could be solved. We think this could be a good idea, but would prefer if someone could organize what happens if/when images break. Without someone performing that product manager role, we think this switch would not be very successful. Does someone here want to take on that kind of work? Broken renderings must be identified, and if the renderer is at fault bug reports filed. If the file was at fault, the file must be fixed -- or at least organized into a list that the community can work from. We could provide a tool for testing individual images, but need people to run through them identifying what's actually wrong (if anything) when a file renders differently.
Dec 28 2020
Due to performance reasons it might be the expected result to not check large SVGs till the end for <switch-tags.
Nov 21 2020
Nov 20 2020
Nov 19 2020
1)For LaTeX there is no need to need to upload a LaTeX-file just put it the source-code into the description.
Gnuplot-Example: https://commons.wikimedia.org/wiki/File:Drini_nonuniformconvergence_SVG.svg#filedesc
LaTeX-Example: https://commons.wikimedia.org/wiki/File:LaTeX_logo.svg#filedesc
Jul 18 2020
@AntiCompositeNumber : Thanks for your answer, I think I was wrong.
Jun 26 2020
May 26 2020
Thanks for fixing! :-D The bug-request seems to be solve
May 15 2020
May 3 2020
@Aklapper I'm not shure if the file is invalid, if I insert the source-code in https://validator.w3.org/#validate_by_input there are only warnings, but no error. (i.e. valid)
Apr 30 2020
@Samwilson I like this solution. (Maybe a bit different wording, as @Glrx explained.)
Apr 28 2020
Apr 19 2020
My guess is that the tool gives up on an entire file when it runs into a pattern that it cannot process.
@Glrx Thanks! The tool is better than I thought. :-D
Apr 18 2020
@Glrx Your descrition does imho not relate to his bug.
Mar 26 2020
Mar 22 2020
I think this issue is caused by T36947
I think this issue is related to T36947
Mar 19 2020
@Esanders : Your bug is imho T217990 and can be fixed using https://tools.wmflabs.org/svgworkaroundbot/ (activate "run svgcleaner"). It is related to missing spaces between arc-to-flags. That is a common SVGO problem, you should try https://github.com/scour-project/scour and https://github.com/RazrFalcon/svgcleaner instead, which are imho less buggy and sometimes even offer woraounds for librsvg-bugs. (so they often repair svgs; and hardly break them)
Mar 15 2020
Mar 14 2020
How can I close/mark it as duplicate of T208620 ?
Mar 2 2020
@Aklapper : According to your comment T193300#4166078, I have to correct myself (T193300#4444133) inkscape uses cairo-backend (also librsvg uses cairo-backend REF ), see https://gitlab.com/inkscape/inkscape/issues/1063#note_297298220 (ping to @RazrFalcon )
Feb 27 2020
Common librsvg-bugs are known and some of them can be checked by Commons:Commons SVG Checker which are listed here: https://commons.wikimedia.org/wiki/Commons:Commons_SVG_Checker/KnownBugs
But writing a bug-checker for malformed files for librsvg-bugs (I did not know such files exist) is maybe even more difficult than render the file correclty. (So ~impossible) (For some few it is maybe possible, but there exist imho not a common one.)
Feb 24 2020
Re-evaluate librsvg
- with non-Commons-files is like comparing apples with oranges (Quting from https://github.com/RazrFalcon/resvg#performance )
- with Commons-files is very tricky, how do you handle malformed files optimized for librsvgbugs, which should render differently according to the SVG1.1-W3C-DTD (and also Browsers normally render according to the standard)? Such as rsvg-Bug565, rsvg-Bug566, rsvg-Bug567 (T246003 T246001 T245864 T246014, but on GNOME you can see it better)
Feb 22 2020
@Aklapper Yes it is about wrong PNG-rendering.
Feb 21 2020
Feb 16 2020
Jan 29 2020
@Aklapper here the data from https://github.com/RazrFalcon/resvg#svg-support
Program | https://www.w3.org/Graphics/SVG/Test/20110816/ | https://github.com/RazrFalcon/resvg-test-suite |
resvg 0.9.0 | 280 (best) | 1261 |
rsvg 2.47.2 | 224 (worst) | 979 |
Inkscape 0.92.4 | 249 | 955 |
Batik 1.12 | 269 | 933 |
Jan 13 2020
Jan 11 2020
@jijiki : The Problem is not persisting for uploaded files(after ?action=purge, since I guess ~2012), but new files can't be uploaded any more, see first Bug in https://commons.wikimedia.org/wiki/Commons:Commons_SVG_Checker/KnownBugs .
Jan 9 2020
Please note "This diagram was created with Inkscape, and then manually edited." under Summary in https://commons.wikimedia.org/wiki/File:Double-slit.svg so this case is not very common. We can take another look if this becomes a bigger problem.
Jan 8 2020
Oct 25 2019
@Aklapper : https://gitlab.gnome.org/GNOME/librsvg/issues/17 should in my opinion be resolved because text-decoration="underline" works but overline doesn't, see https://commons.wikimedia.org/wiki/File:T15495_(resolved).svg , see also https://bugzilla.gnome.org/show_bug.cgi?id=524433 and https://phabricator.wikimedia.org/T15495
Oct 24 2019
Aug 12 2019
Sorry for not answering. I didn't have access to a PC (holyday and repair of my private one) and I am no longer able to reproduce this bug.
Jul 20 2019
Jul 19 2019
https://commons.wikimedia.org/wiki/File:T20936_Hairline_cracks.svg
has hairline-cracks all over (from an actual image: File:Two_way_complex_manifold.svg)
you can't even recognise the image any more. (Firefox has the same bug, but chrome not)
Jul 18 2019
Jul 14 2019
@OSeveno : Change the proposal as you like
Jul 5 2019
Jun 22 2019
Jun 17 2019
I tried it with Chromium 74 on Ubuntu 18.04, with the same result, so it seems to be independend on the browser and OS, so I think it is user-related.
Jun 9 2019
@AfroThundr3007730 : According to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs supporting native client-side SVG rendering seems to be impossible/stalled within the next years, not even for specific SVGs T208578 .
Anyway if someone whats to render it on client-side (f.e. animated SVGs) it is possible T5593#5234639 .
@AfroThundr3007730 : The description is "Please add an option to allow client side SVG rendering.", therfore in my opinion this request/task is resolved, but I would agree there should be another new phabricator-Task about "Native client-side SVG rendering, without relying on third-party scripts".
May 20 2019
@Aklapper
I assume it is a bug related to me (my computer/my browers/my extensions/my preferences/my username/my whatsoever)
May 19 2019
@Niharika : No it still does not work
May 7 2019
@Incnis_Mrsi :
Please check the differences in Rendering between
SVG 1.2 | SVG 1.1 |
May 5 2019
May 1 2019
Apr 30 2019
Thanks for your opinion. You are very exprienced in fonts (attributes,W3C,systemLanguage,...) and I really value your opinion.
Apr 28 2019
Apr 19 2019
Apr 15 2019
@Jarry1250 : Actually since last week librsvg 2.40.20 is installed on servers, therfore we might should change the title. (Update librsvg to 2.40.20 on toolforge)
Apr 14 2019
@Aklapper Was there an recent (this week) update or something?
@Aklapper Was there an recent (this week) update or something?