User Details
- User Since
- Oct 18 2016, 9:01 PM (163 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Glrx [ Global Accounts ]
Aug 12 2019
The original file has a two-line label of "Observation" "Screen".
Jul 20 2019
Jul 18 2019
https://gitlab.gnome.org/GNOME/librsvg/issues/48 GNOME 48 "[BZ#641823] transform="rotate(x)" causes incorrect gradient rendering."
Jul 17 2019
Jun 20 2019
I've skimmed the comments going back about 2.5 years. It looks like most bases are covered.
Apr 30 2019
Looking at Meta SVG fonts.svg suggests:
I've been thinking about this request. Adding more fonts seems like it must be a good idea, but many of the fonts above raise questions. Do we need Fira Sans, Linux Biolinum, Cardo, Junicode, Vollkorn, or Avocado? That a font is free is a requirement for Commons, but that does not mean that every free font should be loaded onto Commons. So I'm left to ponder the meaning of "Missing fonts".
Feb 15 2019
should be subtask of T215835
There was a problem with File:999-percentages.svg when used on toolforge. I suspect toolforge cached a local copy of the file. I uploaded a new version of the file to Commons and purged the Commons File: page. I suspect the purge invalidates conventional WMF servers but not toolforge's cache. Toolforge probably thinks the file is still fresh, so it does not contact Commons to see if the file is still current.
Feb 14 2019
File:999-percentages.svg had issues.
Original SVG preview shows. Changes do not show and trigger another popup.
Should be sub of T215835
No, you should not overlook any transform.
The file has text element stroke and fill properties countermanded by tspan elements. Generally, text should not be stroked in an SVG file unless one is looking for special effects. The "Pinna" rendering is the most dramatic for the bug. Look at "Pinna" in the tool's rendering; only the strokes are visible and the fill is none. On Commons, the text is not stroked but filled with saturated red.
The bug looks like the tool scanned the switch element:
Feb 13 2019
The sustainable text starts out as
Feb 11 2019
I edited File:Human leg bones labeled.svg to clean it up and fix the leaders. Originally, the text elements looked something like:
When the page loads, "sustainable" appears on the image over the radial fill, but then the image is overwritten and "sustainable" disappears.
Just a note about the original files.
Feb 10 2019
These issues arise from the underlying graphics, which are less than ideal for translation.
Jan 4 2019
Thank you for the progress update. I'm happy to hear the good news.
Jan 3 2019
The 380kB file in T212660
Dec 3 2018
This ticket is similar T180923, which complained about fc-list and unknown fallbacks.
Dec 2 2018
My take is it is bad. The fc-list should be an accurate reflection of the fonts available to librsvg. I think that problem was raised in another librsvg ticket.
Nov 11 2018
Nov 2 2018
A better option would always serve small (say less than 20kB) SVG files.
Oct 30 2018
Gnome closed issue 319 on 23 August 2018 with commit https://gitlab.gnome.org/GNOME/librsvg/commit/3d84acca9c11482cb0d2f75d379086be21bd4c91
Oct 24 2018
The good news: Gnome #131 and Gnome #256 have been closed.
Oct 19 2018
Sep 13 2018
The cited example is from File:Neural_crest.svg
Sep 6 2018
Sep 5 2018
There are several issues.
Aug 29 2018
Ignoring subscripts, font shifts, and other exotica:
Aug 17 2018
The Translation possible - SVG category is/was an invitation to use SVGTranslate on the file or to use a graphics editor to change the strings and upload to a new file name.
Aug 16 2018
Aug 15 2018
Quiddy wrote:
Kelvin13 might have good advice. He wrote this page of related guidance (that I just found) https://commons.wikimedia.org/wiki/User:Kelvin13/SVG_text_tutorial , which I wish I had seen a few days ago when I was converting an SVG!
Aug 14 2018
I commend Nikerabbit's brain dump. I'm having trouble paging all the details back in.
Aug 10 2018
Adding TheDJ because this is similar to T201274
Aug 9 2018
Tried to do manual upload, but had problems.
Aug 7 2018
Aug 6 2018
I ran SVGTranslate on [[File:Planetary transit.svg]] and keyed in some bogus translations.
Aug 4 2018
Jul 26 2018
Jul 22 2018
MW does not look at class, so bug is in librsvg. Not clear that it has been reported there.
librsvg mishandles hyphenated languages such as zh-Hans.
MW does not look at transform or filter, so this would be an upstream bug with librsvg. I do not know if it has been reported at Gnome.
Jul 20 2018
I'll put a finer point on it: the suggestion would violate the SVG specification, so it should not be done.
Jul 19 2018
I agree with Perhelion and would close this bug as won't fix. "DejaVuSans-Bold" is not a font-family, so we should not expect a font matcher to find it; we would expect a substitution. That substitution would not be bold because the user did not specify font-weight:bold. Maybe some font matchers will do better, but we should not expect that result.
Jul 18 2018
Also same bug as T64987.
Yes, close this as a dup of T64987.
This is the same bug as T184369. AI is putting quotation marks around the font name, and librsvg gets confused by the marks.
Thanks for developing the code, and thanks for your comments and advice.
Jul 17 2018
At this point, we should not use resvg even if there were a Debian package.
Jul 8 2018
The W3C Validator isn't bad; it just isn't as clever as it once was.
Jul 5 2018
No matter what the priority is, it should be a one line fix to the regex at line 328:
Jun 12 2018
Apparently an upstream bug in librsvg.
May 11 2018
line 328: $viewBox = preg_split( '/\s+/', trim( $this->reader->getAttribute( 'viewBox' ) ) );
line 329: if ( count( $viewBox ) == 4 ) {
May 10 2018
JoKalliauer is correct.
May 6 2018
data: should be followed with a MIME type.
Feb 13 2018
There is nothing wrong with the SVG rendering. The wiki markup produces correct HTML with an img element that displays a Finnish PNG version of the i18n SVG. The image looks fine. The problem is that the fi.WP flagged the addition of the "|lang=fi" parameter as bad wiki markup even though the markup should be correct.
Nov 15 2017
The present bug report is about a few SVG problems. MW supports SVG files with switch element translations. That facility was added a few years ago. It had a few bugs (some not its fault), but it mostly worked. The bugs should be simple to fix. It should not be 250 lines of code.
Will somebody who knows how to use gerrit please pull this abomination back.
Nov 7 2017
The translation tag is Finnish: "tag-virheellinen_wikikoodi"
Nov 6 2017
Oct 27 2017
That's why I said "modulo librsvg's limitations". Librsvg IETF langtag matching only uses the first subtag, so "zh-hans" and "zh-hant" are both treated as if they were "zh". If the "zh-hans" clauses always precede the "zh-hant" clauses, then only "zh-hans" will display.
Oct 26 2017
Hyphenated langtags such as zh-hans are working again at least on en.WP and meta (well, modulo librsvg's limitations). I imagine that implies everywhere because they use the same URL host.
Abandon this patch. It is still confused and far too complicated for issues.
Oct 25 2017
Hahaha. It's just simplest not to mess with the case. I don't see any reason to change it
Oct 20 2017
"With this patch the file page UI will display a dropdown containing all the systemLanguage attributes from the SVG file."
Please abandon 385352.
Oct 13 2017
My take on MW is that the system code uses lowercase langtags everywhere. If I look at language objects, then they will have lowercase langtags such as "zh-hant" rather than "zh-Hant". Only in the display of a langtag to the user is it made IETF canonical, and that is only because it is prettier.
ImagePage.php
line 1057 makes $curLang IETF canonical
line 1058 makes $defaultLang IETF canonical
I'm not a MW programmer and ignorant of gerrit.
Sep 27 2017
In times past, the Commons File: page for a switch-translated file would show a "default" language option along with the explicit systemLanguages used. I don't see that behavior anymore.