Open main menu
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.


Unknown subject

Hello! I'm looking for the categories of these two images. What are the posts? The photographs are taken in Norderney. I can't find the meaning or the name. Thanks for your help. --XRay talk 17:48, 6 November 2016 (UTC)

Moved to Wikipedia. May be better. Thank you. --XRay talk 17:52, 6 November 2016 (UTC)
— Preceding unsigned comment added by DePiep (talk • contribs) 20:13, 10 November 2016 (UTC)

Case sensitive comparison on IETF langtags

zh-Hans does not work
zh-hans does work

Langtag comparisons are not case insensitive as required. Mixed case langtags used to work, but not anymore.

Go to an SVG switch-translated file such as File:First Ionization Energy.svg, select the language Simplified Chinese ("zh-Hans") from the dropdown box, and click go. The preview remains in English. The resulting URL (with "zh-Hans") is:

If you modify the URL to downcase "zh-Hans", then the display works.

What is going on, and how can it be fixed? Glrx (talk) 18:54, 11 October 2016 (UTC)

FWIW, I don't know about the lang tag. "Hans" is a script id not a language, region or country. By Unicode/ISO 15924 it is defined in pattern uppercase/lc/lc/lc. So the uppercase demo first of all should work. Also, the region indicators are all-uppercase: "en-UK", "en-US". With all this, css might very well have defined that the value is case-insensitive. Not solved ;-) -DePiep (talk) 20:03, 10 November 2016 (UTC)
I've been complaining about these issues in many places but have gotten nowhere.
The specification for langtags (not CSS) has the preferred capitalization rules that you point out, but it also insists that all comparisons be done insensitive to case: "en-US" is the same as "En-us".
I've looked at some patches to rsvg. I came away with the impression that rsvg has very confused language switch semantics. SVG says the systemLanguage attribute is a list of langtags. In rsvg, the term "locale" is used instead of langtag. The syntax for a langtag (e.g., "en-US") is different from the syntax for locale strings (e.g., "en_US"). Java has many routines for dealing with these constructs. The rsvg comparison routine (both before patch and after a proposed patch) is severely flawed. See I think Aklapper said that PhiLiP's patch was never installed (I don't know enough about the build process), but the pre-patch code is still wrong. rsvg should take an AcceptLanguage preference list (not a single langtag) and do the systemLanguage comparison correctly; a minor tweak could even handle SMIL allowReorder semantics to do SVG 2.0's best match notion rather than SVG 1.x's first match. But the world is even more messed up than that. I don't know how File:xxx.svg|lang=xx is handled, but there was a comment somewhere that lang is supposed to be all lowercase and it is supposed to be a locale (not a langtag). Certainly lang shows more signs of life with lowercase strings. My sense is that SVG language switch handling is fundamentally broken in at least two places. Furthermore, those writing the code or proposing fixes do not understand the langtag/locale, preference list, and SVG matching rules issues. Consequently, code drift is making things worse. In 2015, "zh-Hans" did the right thing, but no more. Glrx (talk) 01:17, 13 November 2016 (UTC)

Problems with svg

When I upload a svg image, it is shown in Commons without the text in spite of that the text is shown normally if the image is viewed on my computer. --Tohaomg (talk) 01:08, 27 October 2016 (UTC)

@Tohaomg: can you give the name of the file on commons so I can take a look at the file? Offnfopt(talk) 03:22, 27 October 2016 (UTC)
@Offnfopt:, in first and second version of File:PBF KPI logo.svg there must be text, but it is not shown. In the third version I made letters by poligons. --Tohaomg (talk) 10:27, 27 October 2016 (UTC)
The SVG text specifies font-family="Tahoma" and uses the characters "ПБФ". My first guess would be rsvg does not have access to Tahoma (see and substitutes a font that does not have the desired characters. ( Glrx (talk) 18:56, 27 October 2016 (UTC)
@Tohaomg: looks like Glrx beat me to the punch in posting here. I uploaded a new revision that uses text and the 'DejaVu Sans' font since the 'Tahoma' font isn't available on the wiki servers. Offnfopt(talk) 19:38, 27 October 2016 (UTC)

Thank you a lot, but I have another problem. I want to load another file ([1]). It looks perfect on my computer ([2]), but in preview in commons uploading window the text is missing ([3]). --Tohaomg (talk) 19:59, 27 October 2016 (UTC)

Hello Tohaomg, textPath is not supported by librSVG, s. COM:SVG. User: Perhelion 20:41, 27 October 2016 (UTC)
PS: The previous bug seems a lack of the XML-Prolog <?xml version="1.0" encoding="UTF-8"?> as I re-uploaded the same file under file:Test.svg with no error. Because you used XML entities, which need a clear declaration (anyway, entities are not really needed here). User: Perhelion 20:59, 27 October 2016 (UTC)
@Perhelion: thanks for double checking this, I figured the problem was the font or the the missing encoding. I was going to do some uploads to Test.svg myself before posting but there had already been a reply so I thought the issue was already confirmed to be the font. Oddly enough though the original file renders properly on SVG Check which uses the older RSVG version (and perhaps a different font setup). Offnfopt(talk) 21:45, 27 October 2016 (UTC)
Is there some other way to make curved text if textpath is not supported? --Tohaomg (talk) 21:14, 27 October 2016 (UTC)
You'll have to convert the text to a path for it to render properly. If you open the file in Inkscape, select the text then select the Path menu then Object to Path. If you want just one path then after you select Object to Path then select the Path menu again and Combine and it'll merge to one path instead of a separate path for each character. Offnfopt(talk) 21:33, 27 October 2016 (UTC)
Converting the text to a path is a poor option. A better option is to redo the figure so it uses primitives that rsvg can handle. Failing that, upload your SVG file with its text on a path (which nobody will use now) AND a PNG version (which everybody will use now); have both point to each other. People who want to edit the diagram can use the SVG to do the changes; they just need to update the PNG from their SVG editor. WP can use the PNG until rsvg can handle it; then links to the PNG version can be changed. Glrx (talk) 00:22, 13 November 2016 (UTC)

SVG css-title does not show

Demo: title of colored dot (mousehover text) does not show

The css-title of the colored dots does not show (ie, mousehover-text in desktop view). I do may expect that, right? SVG code snippet:

  <use xlink:href="#mark" fill="#cccccc" x="130" y="-59.858000">
     <title>Al 5.9858 eV</title>

-DePiep (talk) 20:13, 10 November 2016 (UTC)

Hello DePiep, it works for me, in actual Chrome and Firefox. User: Perhelion 23:30, 10 November 2016 (UTC)
With me: works only when the image is in full-screen, I found out (Firefox; can not test mobile view). If that is by design, we should close this thread. Or am I missing something? -DePiep (talk) 10:59, 11 November 2016 (UTC)
  Done Yes, that's currently by design, see Help:SVG #librsvg (any interactivity get removed, with exception of language switch). User: Perhelion 21:46, 11 November 2016 (UTC)
It doesn't work as a small image because you're looking at the bitmap image that rsvg constructed rather than the actual SVG file. When you see it in full-screen, you are looking at the raw SVG file (and not rsvg's output). rsvg removes all "interactivity"; rsvg does interpret the language switch, but it produces a separate bitmap file for each language. The rsvg "deep-freeze" comment is disheartening. Glrx (talk) 00:15, 13 November 2016 (UTC)

Write up on the status of SVG 2

Tavmjong Bah (a Inkscape developer) has done a write up on the current status of SVG 2. I'm posting it here for anyone here interested. Offnfopt(talk) 14:17, 12 November 2016 (UTC)

Images displaying in broken colors

I have discovered that about one third of the images in Category:History of Mental Health and Psychiatry Images from Wellcome Library display completely wrong in the web browser on my home computer - the colors are broken (the images are black and white, but display in purple and the like). On my laptop computer they display correctly, and so do they on my work laptop. (By chance, my home computer has Windows 10, and both the two laptops have Windows 7.) They also display correctly when I download them to my computer; I have fixed a couple of them by downloading them, opening them in IrfanView, saving with no changes and re-uploading. (See e.g. File:A doctor visiting a senile old man and discussing his verdic Wellcome V0011460.jpg.) What's going on here? (I remember a similar bug on Harry Potter wiki, where some images displayed upside down - again, they displayed differently in browser and on the system. I also had to fix them opening them in Irfan, rotating them and re-uploading. See e.g. File:GiffardAbbott.jpg.) - Mike Rosoft (talk) 09:04, 18 November 2016 (UTC)

The image you linked to, I looked at the first revision of the image and it uses a color profile called "TIFF RGB". I've never come across this color profile in a JPEG. I downloaded the original JPEG from the wellcomelibrary website and it does not use this unusual profile. I'm not sure if this was caused from the way the wellcomelibrary processed their images in the past and have since corrected the problem. do you recall if you did any automated processing of the images prior to upload? On the image I downloaded from their site, they have a bar appended to the bottom of the image with a watermark, thought you may have used a utility to crop the watermark prior to upload. Not sure if it could have been a parameter you used that could have caused this or if it was from the libraries image conversion+Exif editing. Offnfopt(talk) 10:19, 18 November 2016 (UTC)
Edit: Just to note I haven't seen the problem you experience myself, just looking for anything that stands out with the JPEG. Offnfopt(talk) 10:21, 18 November 2016 (UTC)
There were a handful (maybe 100?) test images where the credit bar was trimmed using a script. This did not happen for the main 100,000 set of Wellcome Images which were given to me on a master disk without any credit bars or other digital changes to the original scan. To research these, I suggest you go to the Wellcome digital library link, and re-download the high resolution version which comes with the credit bar, and probe the settings on that file. It could be that I did the crop (using a standard python PIL call), then re-added the EXIF data using a line command, but it was so long ago that I do not recall exactly what tools I applied or with what settings. In general colour profiles are done poorly on these types of collections, it could be that odd printing profiles were used that work very badly for digital display; I recommend viewing in both Firefox and Chrome side-by-side in on the same computer screen, if there is a profile issue they will display very differently and we normally put this down to long term Firefox bugs (there are tasks on Phabricator that relate to this). -- (talk) 10:30, 18 November 2016 (UTC)


I created a SVG image using matlab, an export function called plot2svg and edited the result in inkscape. Everything seemed good but it does not render here. Has one of you SVG-Ninjas any idea what the problem is? I hope for an explanation rather than a fixed file, hence it is not in its final version. Thank you.--Jahobr (talk) 00:05, 21 November 2016 (UTC)

Jahobr it isn't rendering properly because of your viewBox values. Open your SVG with a text editor and look at the attributes for the SVG tag. Your viewBox is set to viewBox="-252000 0 0 393.75". Think of the document as a x y grid, these numbers define what is visible to the viewer/user. You have the starting x and y position then next is the width and height, so that is viewBox="x y width height". Your viewBox states:
  • starting x position: -252000
  • starting y position: 0
  • width: 0
  • height: 393.75
So the problem is (1) the starting x position is out of range of the visible elements in your document and (2) the width value is set to zero, so even if the x position was in range of the visible elements, the width being set to 0 causes nothing to be visible. Changing the viewBox to 0 0 480 370 corrects the issue. Offnfopt(talk) 03:28, 21 November 2016 (UTC)
Or remove the viewBox property in text editor altogether even though Jahobr is likely to revise this SVG in Inkscape again, it just saves us from worrying that something else would be ruined by Inkscape. -- Sameboat - 同舟 (talk · contri.) 04:33, 21 November 2016 (UTC)
@Jahobr: Also I must point out that you have converted all text to path which for graph like this is not justifiable. It only creates troubles for other contributors who may translate your SVG. -- Sameboat - 同舟 (talk · contri.) 05:02, 21 November 2016 (UTC)
Forget that. I overlooked your initial upload which contains raw text so I do a mass cleanup again to reduce its size from 88k to 38k. Inkscape is weird that sometime it would just convert all XML tags from <element> into <svg:element> which is extremely harmful. -- Sameboat - 同舟 (talk · contri.) 05:27, 21 November 2016 (UTC)
  Done Perfekt. Thank you. I tried to reproduce the this, but now the export is fine. Must have been something I did, while editing in inkscape. --Jahobr (talk) 10:07, 21 November 2016 (UTC)