Thu, Jan 13
Tue, Jan 11
I have mixed feelings about this request.
Fri, Jan 7
Mon, Jan 3
Copying my comment at T5593:
I believe simple Unicode hieroglyphs already display on Windows browsers because Windows has a hieroglyph font.
Wed, Dec 29
Oct 26 2021
Sep 22 2021
librsvg2.50 fails, so Gnome probably does not know about this bug.
May 26 2021
I would decline this ticket. It asks for a mechanism that is not needed.
May 24 2021
May 21 2021
May 20 2021
I agree with you.
May 19 2021
Thanks for volunteering to do this topic and expanding the audience.
@JoKalliauer Thanks for showing that hyphens do not work, that 2.50 shows the default when there is no match, and that simply substituting an underscore for a hyphen does not solve the problem.
@Dzahn Thank you very much. The test results (now removed) suggest that hyphens are death. I do not know why the switch element's default clause "other" was not displayed. That suggests something else is awry. The SVG file validates.
May 18 2021
The Commons file
offers a quick and easy switch diagnostic because it displays the IETF language code.
May 17 2021
May 16 2021
May 9 2021
Yes, that should be the meaning for (default language). It is the meaning that Arthur2e5 expected.
May 5 2021
Here's my take.
May 3 2021
I would decline this task.
If XML or SVG required strong type checking, then attributes such as id=" lg" or id="0lg" would raise exceptions Applications were sort of expected to validate XML input against a DTD and refuse to process bad input. That was a nice theory, but Java would take 6 seconds to validate an XML file, and that was just too high a penalty. So few applications complain about their input. I like it when one of my browsers throws an SVG syntax error.
With a specific locale string of LANG=es_ES.utf8 (which is a transliteration of es-ES to a locale string), librsvg displays systemLanguage="es" text. It should only display text that is at least es-ES. See T261192#7053643
May 1 2021
@RazrFalcon This bug is very low priority; the old librsvg didn't do it right, so it will have almost no impact on WMF's SVG files.
Well, I was hoping for confirmation rather than another setback.
Apr 30 2021
Generally, SVG 1.1 incorporated a subset of CSS 2. Therefore one should be able to use style attributes with url() syntax
- <circle cx="100" cy="100" r="20" style="fill:url('#idname')" />
If CSS url() syntax with quotation marks is allowed in style attributes, then it should be allowed in fill attributes.
@AntiCompositeNumber @JoKalliauer @RazrFalcon
From my Commons talk page ( https://commons.wikimedia.org/wiki/User_talk:Glrx#fill=%22url('#gfuser')%22_allowed ) on 28 Feb 2020:
@AntiCompositeNumber Thanks. A wonderful test.
@AntiCompositeNumber Thanks. Your systems are not setting LANGUAGE. I'm hoping that LANGUAGE being set on jewiki.net explains the behavior.
@Kghbln Thanks for running the tests.
Apr 29 2021
@Kghbln I'm puzzled, too.
We need to simulate what happens in rasterize with a $lang argument at
That is, set LANG environment variable to es and
- rsvg-convert -w 512 -h 360 -o result.png Multilingual_SVG_example.svg
and see if the result is in Spanish.
Apr 28 2021
No. The contents of the SVG files look OK. However, some multilingual SVG files display other languages while others do not. What is different about the working and non-working SVG files? That difference may expose the bug. You proposed that the difference was when the SVG file was uploaded. I looked for differences in the SVG files. It looks like you were right.
Apr 27 2021
The failure happens for simple, non-hyphenated, IETF langtags such as de. Regions are not being set. The system processes some files correctly but fails with other files. That suggests that $LANG=de is not begin expanded into a more complex langtag such as de-DE and then failing to match the available systemLanguage attributes. That files uploaded before the upgrade work sounds like a red herring; all files should be getting the same processing (assuming the cache has been cleared or aged out - ?action=purge did not change the results).
Apr 26 2021
The regex should test that trailing chararacters do not have a left brace or a right brace. A right brace may appear with CSS at-sign rules.
Apr 25 2021
The issue is the Symbol font does not use Unicode code points. SVG agents look at the file and believe they are rendering a "q". If the agent happens to have the Symbol font, then it tells that font to render a "q"; the font's q just happens to look like a theta. Otherwise, the agent chooses a font with normal code points, and that font will paint a glyph that looks like a "q".
I returned BirdBeaksA.svg to the state where it had a nested tspan and ran SVG Translate.
Apr 24 2021
It looks like a font issue to me, and I do not see any of the images as "wrong".
The new version of librsvg is not an acceptable renderer:
- it does not take an IETF langtag (major)
- it does not handle textPath (medium)
A one-character fix is needed.
So the style element tickles the bug.
Tried new version, and it worked.
Apr 23 2021
The issue is much more complicated.
added style element with CRLFs; hope cache times out so it can be tested....
I uploaded the current Conic Sections.svg file but without its style element.
Uploaded test file File:SVG Translate Test - bad langtags.svg
Tried again. SVG Translate may be adding the sr_EC langtags, so I need another way to test this problem.
I (and presumably most of those seeking the font list) want the font list that is on the image scalers; that is, the list of fonts used for converting SVG files to PNG bitmaps. I'm not interested in font lists used in generating PDF files; PDF files can flow their text, so they do not have the same constraints as SVG 1.1 files (which has no flowed text). PDF files also allow subsequent font substitution; that is not possible after an SVG file has been converted to PNG. I could see some PDF users being particular about PDF CJK font choices, but that is not an immediate concern to me.
Apr 22 2021
SVG Translate is still using the old file iwth sr_EC langtags.
I've purged Conic Sections.svg waited half a day, but SVG Translate is working on the old file (with sr_EC langtags).
Apr 21 2021
conf/fc-list has useful information, and there have been several requests for updated information on MW fonts.
I removed the nested tspan, waited for the cache to clear overnight, clicked the SVG Translate link above, and SVG Translate found no text to translate.
Apr 20 2021
The file has deeply nested tspan element: <text><tspan><tspan>Not to scale</tspan></tspan></text>.
$ strings were also reported in T231143.
The issue seems to have been fixed.
I would close report this as won't fix. Quite simply, SVG Translate requires Commons to serve files with the correct content-type header,
and Commons should serve SVG as image/svg+xml.
The same problem happened to that file again.
Apr 11 2021
Apr 10 2021
The code should never be looking for underscores in a systemLanguage attribute.
I noticed that one user made several Kurdish translations in Arabic script that failed to show up. Looking at the SVG, the files had systemLanguage="ku_ARAB" instead of systemLanguage="ku-Arab" (capitalization is not important).
Apr 4 2021
Apr 3 2021
I would decline this request. The creator should always specify a size.
Apr 2 2021
This basic problem is reported in T270889.
Mar 10 2021
Thanks for the note about @ sections. I'd like to see support for (color) and not (color), but that is beyond SVG 1.1.
Thanks for running the test. Resvg has more support than I expected.
Mar 9 2021
Thanks for trying it.
Mar 8 2021
IIRC, resvg uses a simple CSS parser. Could you try rendering
tests several SVG 1.1 (CSS 2) selectors.
Mar 2 2021
First, the indicated SVG file, https://commons.wikimedia.org/wiki/File:Multilingual_SVG_example.svg has one switch element with several language clauses. Currently, it does not have a default final clause (i.e., a text element without a systemLanguage attribute). Consequently, if there is not an explicit langtag match, the switch element should not render any text. For the case of "(default language)", no text should be displayed.
Feb 28 2021
I was faked out. Long ID names do work. The file probably has other issues (linearGradient, isolation:isolate, or mix-blend-mode:overlay).
Two proposals: increase the number of bytes read or shift multilingual testing to upload time (when the file is read anyway).
Feb 27 2021
I would close this issue as won't fix.
Nov 25 2020
My current understanding is that WMF already does some sanitization of SVG files.
Nov 20 2020
Where to begin?
Oct 17 2020
SVG language name handling is a mess on many levels.
May 14 2020
This issue is the same as T36947. Font sizes in original Command_Pattern.svg were below 5px.
May 10 2020
The tool should also give a reasonable error message for