flowroot does not appear
tracked in phabricator task t43424
a picture containing svg1.2-valid flowroot
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.
tracked in phabricator task t180923
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".
- converting the text into paths increases file size, and is therefore generally disfavored (except for text logos, etc.).
- 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.
bad letter-alignment on small font-size
tracked in phabricator task t36947
librsvg calculates the letter-distances inaccurantly for font-sizes of 20px and below.
for a text like
<svg viewbox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
<text x="20" y="30" font-size="5px">exampletext</text>
you can replace it with:
<svg viewbox="0 0 1000 1000" xmlns="http://www.w3.org/2000/svg">
<text x="200" y="300" font-size="50px">exampletext</text>
<svg viewbox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
<g transform="scale(0.1)"><text x="200" y="300" font-size="50px">exampletext</text></g>
missing embedded jpeg images
tracked in phabricator task t193929
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.
mediawiki (the software from which wikipedia is run) uses the librsvg-library to rasterize all of its svg files. the version of the rsvg program that is installed on wiki does not always correctly raster the inkscape or openoffice.org svg files. the file manager gnome files or c:commons:commons_svg_checker relies on librsvg, so it can be used to check the quality before a svg is uploaded.
rendering inkscape files
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 ctrl+alt+c, 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.)
rendering openoffice.org svg files
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)
tspan x="([0-9]*) ([0-9 ]*)"
this svg export procedure has been tested using oo 2.3.0 and oo 3.2.1 with a simple .odg candidate.