User Details
- User Since
- Oct 18 2016, 9:01 PM (362 w, 5 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Glrx [ Global Accounts ]
Mon, Sep 25
Thu, Sep 21
Another complaint:
Another user complaining about en failing:
*https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&diff=prev&oldid=803253221#Clitoris_Anatomy_labels
Another user running into this issue:
Sun, Sep 17
Sat, Sep 16
Wed, Sep 13
When a URL does not specify lang, then set env to {'LC_ALL': 'en'} so rsvg-convert` knows the language should be English ("en").
Sun, Sep 10
Another user has problems:
Sat, Sep 9
Tue, Sep 5
Gnome issue is
Reopen. Regression error.
To fix T344564 (font fallbacks), we need to upgrade to at least librsvg 2.48.5.
The font specification is done with
style="font-family:Lato, 'Helvetica Neue', Helvetica, Arial, 'Liberation Sans', sans-serif;font-size:18px;background-color:white;text-rendering:geometricPrecision;-webkit-font-smoothing:antialiased" style="font-family:'Playfair Display', Georgia, 'Times New Roman', 'Liberation Serif', serif"
Another file is displayed incorrectly.
Aug 10 2023
Another significant file on Commons that has the problem:
Aug 9 2023
This issue was fixed in the 2.40 C-version of librsvg.
Jul 31 2023
Jul 30 2023
It looks like the file does not have a translation in the first 256kB.
Jul 16 2023
This issue is a dup of T97233.
Renderer miscalculates the width of a text chunk.
Jul 12 2023
The SVG file displays Portuguese:
Reopen. Fix not complete.
The current version of the file uses Unicode subscripted numbers AND a dy attribute:
Jun 29 2023
This appears to be the same bug as T97233. That bug claims to be fixed in librsvg 2.50.2.
The problem is computing the width of an SVG "text chunk". If the text chunk consists of multiple XML nodes, then librsvg is using the width of the last node as the width of the entire text chunk. (librsvg is correctly tossing out the initial and final whitespace for the text element.)
Jun 10 2023
Jun 6 2023
May 29 2023
May 26 2023
May 25 2023
This bug affects a rather prominent SVG:
May 24 2023
Some comments.
May 22 2023
This bug should affect all multilingual SVG that does not use English as the default.
May 21 2023
May 20 2023
May 19 2023
The approach is reasonable.
May 18 2023
T280718: Re-evaluate whether keeping around https://noc.wikimedia.org/conf/fc-list is a good practive
Many Noto fonts are in the fc-list, but NotoSansCJK is not Even "CJK" is not in the fc-list.
I do not see NotoSansCJK in the fc-list.
Duplicate en clauses had already been fixed.
There is/was an issue with duplicate en clauses.
See https://commons.wikimedia.org/wiki/File_talk:2022_Russian_invasion_of_Ukraine.svg/Archive_4#SVG_Translate_trouble
May 15 2023
SimHei and FZYXJW--GB1-0 are not in the font list copied at T280718 or the current https://noc.wikimedia.org/conf/fc-list
The file https://commons.wikimedia.org/w/index.php?lang=qct&title=File%3AHistory_of_the_Universe_%28multilingual%29.svg uses the default font and displays the langtags qcs and qct correctly. Says the default font displays Chinese correctly.
The file https://commons.wikimedia.org/wiki/File:History_of_the_Universe-zh-hant.svg has font-family="SimHei".
May 9 2023
May 8 2023
Generating new requests and looking at HTTP response headers suggest Thumbor version correlation:
https://commons.wikimedia.org/wiki/File%3AAbdomal_organs_body.svg may have the same problem. It's default language is English, but not all of its translations display. The set of working translations also varies. Right now, German (de) works but Spanish (es) displays English. The corresponding image URLs are
May 1 2023
Apr 25 2023
When MW builds the page, it considers lang=en to be the default, so MW uses the src attribute
That URL does not specify a langtag for the SVG file.
I would decline this task.
Mar 21 2023
I would decline this feature request.
Mar 3 2023
Serving SVG or PNG should be determined by the SVG file size. What is the best way to handle that choice?
I would decline this task. WMF is not in the tool business, and the tool would require enormous/impossible sophistication.
Many users want SVG served: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multimedia_and_Commons#Native_SVG_support
Mar 2 2023
This option is very clever. It was a way to efficiently offer both PNG and SVG.
Feb 9 2023
First, @font-face with src should not be used in the vast majority of SVG files. Most SVG files need only basic fonts that can be fulfilled with the sans-serif or serif generic fonts. Even if a graphic designer has a favorite font, graphics uploaded to Commons should use fallback fonts.
In most cases, SVG should use generic fonts and be designed to work with substituted fonts.
Jan 21 2023
Dec 11 2022
The SVG file https://commons.wikimedia.org/wiki/File:History_of_the_Universe-zh-hant.svg has been fixed.
Nov 30 2022
Nov 3 2022
Oct 11 2022
I presume you are using --zoom
Oct 4 2022
I doubt that adding the namespace declaration changes the SVG file's elements. The document has already been parsed, so all the elements have had their namespace property set. SVG Translate is using a poor namespace model, so it will treat elements in the default namespace the same way as it would treat elements in the SVG namespace. SVG Translate uses getElementsByTagName() rather than getElementsByTagNameNS(). That poor model is also why the code separately checks for "svg:text". It should not be doing that. T316741: Allow svg namespace prefixes other than 'svg'
Oct 3 2022
I'm looking at tests/Model/Svg/SvgFileTest.php, and I see test cases such as the two starting at line 645
'CSS too complex' => [ 'svg' => '<svg><style>#foo { stroke:1px; } .bar { color:pink; }</style><text>Foo</text></svg>', 'message' => 'structure-error-css-too-complex', 'params' => [0 => ''], ], 'tref' => [ 'svg' => '<svg xmlns="http://www.w3.org/2000/svg" version="1.0" xmlns:xlink="http://www.w3.org/1999/xlink"> <defs><text id="tref-id">Lorem</text></defs> <text id="text"><tref xlink:href="#tref-id" /></text></svg>', 'message' => 'structure-error-contains-tref', 'params' => [0 => 'text'], ],
The first case does not have an xmlns: namespace declaration, but the second does.