Javasatu:SVG help

Dari Wiki Javasatu
Loncat ke navigasi Loncat ke pencarian
Berkas:Ark-icon.svg
Create a new request
Berkas:Ark-icon.svg

Pengguna:MiszaBot/config Templat:Skiptotoctalk

SVG help Templat:See Scalable Vector Graphics is a commonly used file format for providing a geometrical description of an image using basic objects such as labels, circles, lines, curves and polygons. An image can be reduced or enlarged to an arbitrary size, and will not suffer image data loss, nor will it become pixelated. SVG makes an excellent format for artwork, diagrams and drawings. SVG images are defined in XML text files. This means that they can be searched, indexed, scripted, and compressed. Since they are XML files, SVG images can be edited with any text editor, but SVG-based drawing programs are also available.

However, the rendering engine used by wiki is not perfect, and may cause the image to be shown incorrectly, or differently from how it is displayed in your vector editor of choice. This page enables authors experiencing problems with SVG graphics to obtain some help in getting their images into wiki the way they intend.

Things we can help with


Understanding SVG

  • Questions about the SVG format

Using SVG appropriately

  • When to (or not to) use SVG

What you see is not what you get

  • Missing objects from files
  • Random filled boxes in the image
  • Images that are the wrong size
  • Font inconsistencies
  • Other weird and wonderful bugs

Something new

  • Questions that you can't find a better place for

Generating SVG files[sunting sumber]

There are two classes of problems with using tools to generate SVG files. The first is that tools may generate SVG files that are hard to localize or bloat SVG file size. The second is that the SVG files generated may not be rendered correctly by wikimedia software as PNGs for embedding in Wikipedia pages. This section includes guidance on using software to generate SVG files, including post processing cleanup in a text editor that may be necessary to get a good result.

Changing SVG files[sunting sumber]

SVG files are readily viewable in text editors. To alter a file without disrupting them on Wikimedia, download the file, open it in a text editor to experiment with your text changes, and review the changes in a browser before uploading a new version. For involved edits, you can use a non-destructive editor like Inkscape. Other editors may digest the code and produce outputs in their own SVG format, introducing bugs in the process.

Inkscape SVG files[sunting sumber]

There is a simple work-around for the scarcities of librsvg. The operation "Stroke to Path", to be found under Menu>Path in Inkscape or via Templat:Key press, can be applied to all of the objects that are not rendered correctly. To keep the SVGs editable, this should only be done to the files intended for upload, and these files can be deleted afterwards.

As of February 2014, the objects that must be modified to render correctly by librsvg include:

  • Lines with arrow heads (the arrows need to be converted)
  • Text, that has been transformed, e.g. "Text on Path"
  • Compound objects created with the binary path tools (union, intersect etc.)

OpenOffice.org SVG files[sunting sumber]

OpenOffice.org SVG files may require manual modification before being uploaded to Wikipedia. To achieve this:

  • Change all fonts to Wikipedia supported fonts as mentioned before. (E.g. change "Sans embedded" to "DejaVu Sans".)
  • Add "px" to all font-size references. (E.g. change "font-size:100" to "font-size:100px".)
  • Remove all additional x coordinate references in tspan elements. (E.g. change <tspan x="17583 17917 " y="10943"> to <tspan x="17583" y="10943">.)
  • [Not required for OO 2.3.0] Explicitly colour all text (e.g. black) by replacing relevant "stroke:none;fill:none" instances with "stroke:none;fill:rgb(0,0,0)" (note that simply explicitly colouring text black in OpenOffice 3.2.1 does not appear to work).

NB: Vector graphics line widths may also need to be set explicitly in OpenOffice.org Draw.

SVG code replacement guide (executing replace all using Nedit regular expressions)[sunting sumber]

Original text Replacement text
Sans embedded DejaVu Sans
tspan x="([0-9]*) ([0-9 ]*)" tspan x="\1"

This SVG export procedure has been tested using OO 2.3.0 and OO 3.2.1 with a simple .odg candidate.

Microsoft Powerpoint SVG files[sunting sumber]

It is easiest to save entire slides from Powerpoint as svg rather than saving multiselected objects with right click / save as picture, because for entire slides the boundaries will be cropped to the size of the slide and the background will be set to white. To save slides as svg, use file / save as / browse / save as type --> svg.

If your slide has text, open the exported svg into Notepad and replace all the existing font-family specifications with font-family="Liberation Sans,sans-serif". This specification will make Wikimedia render SVG fonts similarly to how browsers render Wikipedia fonts.

Text can also get chopped up on export, which causes rendering and localization bugs. To fix this, search for all </text> tags and make sure the tag isn't embedded in another text tag that's on the same line of text. Most embedded text tags can simply be deleted; however, but if content needs to be subscripted or subscripted, then replace the text tag with a tspan specifiction. For subscripts, use <tspan font-size="smaller" baseline-shift="sub">. For superscripts, use <tspan font-size="smaller" baseline-shift="super">.

Generating SVG charts from Microsoft Excel[sunting sumber]

Pengguna:RCraig09/Excel to XML for SVG

Text guidance[sunting sumber]

Use text over paths[sunting sumber]

Converting text in an SVG file into paths (shapes) increases file size and prevents localization and accessibility features like text to speech, and is therefore generally disfavored (except for text logos, etc.) The wikimedia text rendering engine can introduce bugs as its fonts may differ from browser fonts or SVG editor fonts, but following the guidance below should minimize them.

font-family property[sunting sumber]

Templat:Tracked

Berkas:SVG Text Font Test.svg
Fallback fonts

Due to copyright restrictions, MediaWiki cannot use proprietary fonts that are commonly found on several proprietary operating systems. Fonts such as Geneva require licensing fees to distribute. rsvg will not be able to locate such fonts, and the text will fail to appear in the rendered image. There are three solutions to this issue:

  • One can substitute a font that is available on Wikipedia. This approach facilitates editability.
  • One can specify a generic font-family such as "sans-serif", "serif", or "monospace", but this can lead to inconsistent rendering. It is better to specify a font available on Wikipedia (such as Liberation Sans) with fallback fonts such as: font-family="Liberation Sans,Arial,Helvetica,sans-serif", in which you define a font-list with similar fonts that at least contain one font for each Operating System such as Wikimedia (e.g. Liberation Sans), Windows (e.g. Arial), Linux (e.g. Liberation Sans), Mac (e.g. Helvetica).
  • Since local rendering should be as close as possible to Wikipedia, it should use locally the same font as it will have on Wikipedia, if available. Therefore always define a Wikimedia-font first. Also, Wikimedia has synonyms for substituting fonts, such as "Arial" for "Liberation Sans"; therefore font-family="Arial,DejaVu Sans" will be rendered by "Liberation Sans" and not (as expected) by "DejaVu Sans". (This is because "Liberation Sans" has the same letter size as "Arial" [metric-compatible], so it is less likely to mess up the text flow.)
  • Group the text, create a copy, and convert the copy to paths. Then either:
    1. move the original, editable non-path text into a separate editable text layer that you make transparent (warning: this might be removed by SVG optimizers), or
    2. move the original, editable non-path text outside the visible area (example: File:Essigsäuresynthesen.svg).

For ease of subsequent editing and significantly smaller file sizes, substituting the font with an available font is recommended. Many common fonts have non-proprietary alternatives that are similar in typographical style, resulting in minimal disruption to existing images during substitution. For a list of fonts available in Wikipedia, see available fonts on Meta.

Wikimedia has default fonts, and will use Liberation Serif for Times New Roman and Liberation Sans for Arial. For further fallbacks see c:Help:SVG#fallback.

Fonts that are available on Wikimedia servers may or may not be available on a visitor's machine. If the placement or appearance of text in the image is important and there is uncertainty about which fonts are installed on a visitor's machine, then converting text into path information may be necessary.

font-size property[sunting sumber]

Berkas:20200522 SVG font rendering at different thumbnail sizes.gif
Rendering anomalies may occur in thumbnail views if small font sizes are used. Declaring font-size="35" (or larger) appears to avoid this problem, depending on the pixel size of your graphic.

Fonts should be sized so that they look good as thumbnails on wikipedia pages and so they are easy to view on smartphones. Smartphones are how most people access wikipedia. Thumbnails are how most other people see images, as very few people click images and zoom them in to see them. Avoid using or creating images with fonts that are too small to be legible in thumbnail or smartphone views.

The font size that appears in a thumbnail is a combination of svg width, thumbnail width, and font size. To match wikipedia font size as a thumbnail, use font-size = (63/(your upright value))*((your svg width)/1000). For instance, if the thumbnail will be scaled up to thumb upright=1.35 and your image has svg width of 960, set font-size in the svg to (63/1.35)*(960/1000) = 44.8.

Background colors[sunting sumber]

Transparent backgrounds are fine, but do not think your image will always be displayed on a light or white background. The wikipedia smartphone app, for instance, renders images on a black background, so if you show black text on a transparent background it will be invisible.

Testing for problems[sunting sumber]

The following SVG checkers may help you to detect SVG problems before you upload:

None of these checkers are foolproof, so it's wise to validate images. You can preliminarily validate images by uploading them to the shared, temporary-use location Test.svg, though other users may overwrite your image at any time.

To force refresh images in your browser use Ctrl+F5 (Shift-Reload on Mac), so that you see the latest upload and not cached image copies (this is necessary even on wikimedia upload pages).

Rendering SVG files[sunting sumber]

On Wikipedia SVGs are interpreted by the librsvg-library to create PNG previews at different image sizes (to rasterize them). That library only recognizes a subset of all valid SVG syntax, and may render your SVG without many features.

In order to bypass these deficiencies in the library, there are certain parameters that need to be formatted in specific ways or be assigned a workaround value in order for librsvg to accurately render views of your SVG file. Some issues are enumerated below, but be sure to test your SVG files before and after uploading them.

<mask> parameter maskUnits="userSpaceOnUse"[sunting sumber]

The librsvg-library does not interpret the value of "userSpaceOnUse" for the parameter maskUnits correctly. To bypass this issue, replace maskUnits="userSpaceOnUse" with maskUnits="-10% -10% 120% 120%", and the SVG mask will render properly on Wikipedia.

parameter stroke-dasharray[sunting sumber]

The librsvg-library does not accept a stroke-dasharray parameter with values separated by spaces. Replace all spaces with commas to bypass this issue: e.g. stroke-dasharray="2 3 2 4"stroke-dasharray="2,3,2,4"

Use xlink:href=, not href= alone, in <use ___/> statements[sunting sumber]

In Wikimedia projects, <use xlink:href="#myobjectname" transform="translate(10 10)" /> will render properly if you have specified xmlns:xlink="http://www.w3.org/1999/xlink". Be aware that href= by itself will not work on Wikimedia projects even though it might render properly if directly read by your browser.

CSS selectors or identifiers must start with a letter or hyphen[sunting sumber]

http://w3.org/TR/css-syntax-3 states, "Property names and at-rule names are always identifiers, which have to start with a letter or a hyphen..."

Common problems[sunting sumber]

flowRoot does not appear[sunting sumber]

Berkas:Error-libsvgr-flow.svg
a picture containing SVG1.2-valid flowRoot

Templat:Tracked If black box appear, read c:User:JoKalliauer/RepairFlowRoot how to solve this issue, but do not remove those objects since they might contain text. The workarounds that one can employ are either not to use flowed text (by using the text tool without creating a text field), or convert the text to normal text (by Text-editor or sed-comand, or with Inkscape-GUI or with a Inkscape-batch), but to stroke the text using "object to path", since path-text is not recomended and increases file-size.

Missing embedded JPEG images[sunting sumber]

Templat:Tracked

When a raster graphic is embedded in an SVG it is encoded into base64 data. That data is then assigned a MIME type in the <image> element. In the case of an embedded JPEG, the MIME type is "image/jpeg". Older versions of Inkscape (and possibly other editors) assigned the MIME type "image/jpg". While Inkscape and most web browsers will display such an SVG image just fine, the MediaWiki software that rasterizes the SVG file will have trouble with it. Not recognizing the MIME type "image/jpg" there will simply be an empty space where the image is supposed to be. The fix is to open the SVG file in a text editor, find the <image> element, locate "image/jpg", change it to "image/jpeg" and re-save. At right is an example of this problem. The Commons SVG Checker looks for this problem; see Commons:Commons:Commons SVG Checker/KnownBugs#Checks for details.

Though Web browsers cope with image tags without width and height specified, librsvg ignores such images.

Further issues[sunting sumber]

Further issues can be found at c:Librsvg_bugs or at Commons:Commons:Commons SVG Checker/KnownBugs, and examples can be found at c:Category:Pictures_demonstrating_a_librsvg_bug. However most issues (for files <1MB) can be fixed using https://svgworkaroundbot.toolforge.org/ (enable "run svgcleaner" and enable "run scour" before clicking convert), for a more detailed list check c:User:SVGWorkaroundBot.

Assistance[sunting sumber]

If you have a tricky SVG file with a problem not described, or can't quite figure out what the previous section was talking about, you can simply ask for assistance by posting a quick note hereafter that outlines the problem, as well as providing links to the files that are exhibiting these problems. Don't forget to sign your name with four tilde symbols (~~~~) and an editor will attempt to reply here to help!

When you are happy that a request has been fulfilled, just leave a note so that the request can be archived later, as needed.

An alternative source of help is Commons:Graphics village pump.

Current requests[sunting sumber]

Templat:Archive box

Create a new request

Why are long OWID SVG map captions being overlapped by logo again?[sunting sumber]

Templat:Tracked

Note: I posted here and never got a response in over a week: Commons:Graphics village pump. I deleted my post there. --Timeshifter (talk) 12:54, 17 July 2023 (UTC)

I thought this was solved. See Feb-Mar 2023 thread:

Our World in Data (OWID) maps are using the same font-family CSS from when the problem was first solved:

style="font-family:Lato, &#x27;Helvetica Neue&#x27;, Helvetica, Arial, &#x27;Liberation Sans&#x27;, sans-serif;"

What has changed? How can the problem be fixed? See also:

I see this list of substitutions:

It is here: Commons:Help:SVG#Font substitution and fallback fonts. Are fallback fonts with wide character spacing being substituted for fonts with narrower character spacing? DejaVu Sans has wider characters and/or spacing than the other Sans substitutions. Is it being substituted?

Also, is there any reason OWID can't use regular quotes like this around the multi-word font names?:

style="font-family:Lato, 'Helvetica Neue', Helvetica, Arial, 'Liberation Sans', sans-serif;"

Are the single quotes necessary at all? Are the commas enough to separate the font names?

See older confusing thread from Dec 2021:

See some of the maps in question:

They are all using the same font family list. --Timeshifter (talk) 12:54, 17 July 2023 (UTC)

http://stackoverflow.com/a/13752149 states
Cheers, cmɢʟeeτaʟκ 15:15, 17 July 2023 (UTC)
Thanks Templat:U. So since OWID fonts only have A-Z text in their names, then this would work fine on Wikipedia and elsewhere?:
style="font-family:Lato, Helvetica Neue, Helvetica, Arial, Liberation Sans, sans-serif;"
The spec link is this:
https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#propdef-font-family
Can OWID's logo overlap problem on Wikimedia be solved by putting Liberation Sans first in that font-family list? --Timeshifter (talk) 08:18, 18 July 2023 (UTC)
Re "this would work fine", I think so. Re "OWID's logo", no idea. Give it a try! cmɢʟeeτaʟκ 15:48, 18 July 2023 (UTC)

Templat:Outdent Templat:U. *c:Commons:Commons SVG Checker. When I run one of the problematic OWID files through it I get this message:

"WARNING: XML declaration not found and is strongly recommended"

How is that fixed? Can someone look at the SVG code for this file?:

When I run the SVG template map through it I get this:

"Nimbus Sans L is not available in Wikimedia software."

So I will remove it from the font-family list.

Removing "Nimbus Sans L" from a map upload to the Shoutwiki wiki solved a major problem there. It got rid of the little squares that were substituted for characters. So now the map SVG is:

 <g font-family="Liberation Sans,Arial,Helvetica,sans-serif" font-size="18" letter-spacing="-1px" text-anchor="middle" stroke-width="0.2" stroke-linejoin="round">

--Timeshifter (talk) 04:09, 24 July 2023 (UTC)

The XML declaration is the line
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
and it goes before the <!DOCTYPE ...> (if one is present) or the <svg ...>} (if not). Some SVG processors tolerate its absence, but not all, so it's best included. Mentioned often in the SVG 1.1 spec (see e.g. chapter 5 Document Structure), it's not described there but at section 2.8 Prolog and Document Type Declaration of the XML spec. --Redrose64 🌹 (talk) 20:39, 24 July 2023 (UTC)

Templat:Outdent Templat:U and others. I ran this map

through this validator:

There was a long list of results. Here is a direct link.

Does any of it make sense to you? What is important? I intend to contact the webmaster at OWID with what we have figured out so far. --Timeshifter (talk) 10:35, 27 July 2023 (UTC)

Aklapper at Templat:Phab noted something major that we all missed. The title of the task is his after he changed it from my original title, "Change in SVG font substitution is messing up images", to the more specific "Font substitution for SVG file to PNG thumbnail replaces serif with sans-serif font".
The title (the very top line in the image) is supposed to be a serif font. It is that when rendered outside MediaWiki. But MediaWiki makes it into a sans-serif font.
I think MediaWiki is ignoring the SVG file's font-family lists for both serif and sans-serif fonts. And then substituting a wider sans-serif font such as DejaVu Sans. --Timeshifter (talk) 03:57, 20 August 2023 (UTC)
Regarding the "long list of results", the problem here is that you are attempting to validate the file description page, not the image that it relates to. Try this link instead, which returns one info entry and two errors.
As for the comment at phab:T344564#9104543 about "ERROR in <style>: It will not be rendered properly by Wikimedia's SVG renderer. As workaround add attribute type="text/css" to <style>. See https://phabricator.wikimedia.org/T68672 for details.", this means that you should use <style type="text/css"> everywhere that you have used a plain <style> tag. It's documented at c:Help:SVG#Stylesheet as a known quirk of librsvg. --Redrose64 🌹 (talk) 11:01, 20 August 2023 (UTC)
Thanks again, Templat:U. I put that info in phab:T344564#9104543. I also added the results from https://validator.w3.org/#validate_by_upload for the latest map file (the one that can't be uploaded to the Commons).
Templat:U, Templat:U, and others. It would be nice if someone who knew what they were doing could fix all the errors in that file and try uploading it again. I don't understand a lot of this stuff since I am not an SVG image creator. I have edited the user-editable parts of some SVG files created by cmglee. That's about it.
I am wondering if fixing all these errors fixes the main problem at phab:T344564 of incorrect font substitution. If it does, we can contact the OWID webmaster and point out the problems and solutions. So that his SVG files work correctly on Wikipedia. --Timeshifter (talk) 20:00, 20 August 2023 (UTC)
Before anyone tries to "fix all the errors in that file", we should consider how the file was generated. If automatically by OWID software, someone should fix that instead. Otherwise, the next time another file or update is generated, one will have to go through the whole process again. Cheers, cmɢʟeeτaʟκ 22:15, 20 August 2023 (UTC)
The original Wikipedia fix described in the OWID Github thread happened after I contacted them. So if we figure out the problem we can point them to the solution, and let them fix the software. Contact:
https://ourworldindata.org/about#contact
OWID also makes available their free open-source software for others to use:
https://ourworldindata.org/owid-grapher
So we want that to be Wikimedia compatible too.
Templat:U, Templat:U, and others. I sent an email to info@ourworldindata.org and pointed them to phab:T344564. --Timeshifter (talk) 05:49, 23 August 2023 (UTC)

Missing circular arcs[sunting sumber]

Berkas:Perfect circular Golomb rulers.svg
Arcs are missing

The circular arcs in this SVG's thumbnail are not rendered. They were visible when I uploaded the file in 2020. Shift-refresh and action=purge didn't fix the issue. Can someone please check? Thanks, cmɢʟeeτaʟκ 18:50, 21 August 2023 (UTC)

Templat:Done Seems to be working now. cmɢʟeeτaʟκ 12:27, 23 August 2023 (UTC)

A mistake in a SVG File[sunting sumber]

Hello,
there is a mistake in File:Al Nassr FC.svg, the originale Logo in the website team doesn't look like the same.
look the file on the right. Can anyone check it? Thanks. File:Logo Al-Nassr.png-- أيوب (talk) 16:14, 29 August 2023 (UTC)

The original logo on the team website is https://siteapi.alnassr.sa/files/settings/2022-09/16/sVXvhuCPwi32RnUpf9k9ztz3dEMyW6LL.png and I don't see what the problem is with File:Al Nassr FC.svg. --Redrose64 🌹 (talk) 17:58, 29 August 2023 (UTC)
@Redrose64 first Templat:Thank you for reply,
i hope you keep the file bcs SVG is better in logos,but the problem in SVG file is there up in the crown a yellow collor that doesn't exist in the original logo.-- أيوب (talk) 18:34, 29 August 2023 (UTC)
This extra yellow is the part from the <g fill="#ffd02d"> tag to the next </g> tag and all of the <path ... /> tags that they enclose, inclusive. If removed, the crown shows as a solid blue. --Redrose64 🌹 (talk) 22:33, 29 August 2023 (UTC)

File:Coat of arms of Urquhart of Urquhartt.svg[sunting sumber]

I uploaded File:Coat_of_arms_of_Urquhart_of_Urquhartt.svg to commons but the shading of the dogs does not display on page, it does however display if you click on image and then click again to zoom in, how can I correct this? I tried putting object to path, but this did not help. Yours ever, Czar Brodie~commonswiki (talk) 22:45, 4 September 2023 (UTC)

I haven't looked at the file, but when you're clicking "to zoom in", that means the SVG is being displayed directly in your browser without the involvement of Wikimedia software, while the other view is the SVG being rendered to raster by Wikimedia. AnonMoos (talk) 00:54, 5 September 2023 (UTC)
If I understand correctly the problem is with wikimedia. Is there a way round this? To correct the file so Wikimedia understands it? Czar Brodie~commonswiki (talk) 19:54, 6 September 2023 (UTC)
Wikimedia has nothing to do with it. AnonMoos is probably thinking of MediaWiki, but that also is not the culprit. The MediaWiki software serves the pages and images, but the image that is served is a PNG conversion from the SVG original, and the conversion is performed by librsvg. --Redrose64 🌹 (talk) 21:35, 7 September 2023 (UTC)
A little passive aggressive are we? I meant "the software running on Wikimedia sites", an allowable synecdoche. The important thing is to distinguish when the SVG is being rendered in the user's own browser, and when it's being rendered by the site's software. By the way, I looked at the SVG in one browser (not the most up to date) and it looked much the same as in the Wikimedia-served PNG... AnonMoos (talk) 10:17, 8 September 2023 (UTC)
problem solved, I redrew the dogs and manually filled in the colour variations without any fancy group shading. Yours ever, Czar Brodie~commonswiki (talk) 20:33, 16 September 2023 (UTC)

SVG cropped out on Media Viewer[sunting sumber]

At File:Cricket, 2022 Asian Games.svg, which I extracted from pdf using Inkscape, why when viewing through Media Viewer the ball on the right look cropped out. It looks fine when clicking "Original file" at that file page. Hddty (talk) 13:54, 18 September 2023 (UTC)

When you click on "Original file", that means the SVG is displayed directly in your browser, not through Wikimedia (see section above). AnonMoos (talk) 19:28, 18 September 2023 (UTC)
How to fix this? Hddty (talk) 00:49, 19 September 2023 (UTC)
Templat:Done, Templat:Ping I updated the SVG's width to equal its height, and its viewBox accordingly to centre the image, as in the thumbnail. cmɢʟeeτaʟκ 23:02, 20 September 2023 (UTC)
@Cmglee Thanks. Why is the PNG rendering of SVG not exact? And so to fix this problem, width and height should be equal? Hddty (talk) 09:34, 22 September 2023 (UTC)

SVG logo rendering issue[sunting sumber]

This file File:Ele.me logo.svg is not rendered correctly on the page. Can someone help me fix it? Thanks. Larryasou (talk) 08:35, 21 September 2023 (UTC)

Templat:Ping The fourth and fifth parameters (large arc and sweep flags) for the arc (a or A) command in the path tag must be delimited, e.g. by spaces or commas, to render correctly in rsvg. For instance,
a7.147 7.147 0 011.77-1.306
must be replaced by
a7.147 7.147 0 0 1 1.77-1.306
– see https://phabricator.wikimedia.org/T217990 for its Phabricator ticket.
Cheers,
cmɢʟeeτaʟκ 23:57, 21 September 2023 (UTC)