I'm trying to position SVG text so that it site entirely above the y-location at which it is located. A dominant baseline of text-after-edge appears to be the appropriate setting for this.
This works just fine in Chrome, but with Safari text-after-edge renders with the text centred around the y-location.
I explored further, as seen in this codepen:
https://codepen.io/anon/pen/obrreb?editors=1010
Here is the output in Chrome:
And in Safari:
As you can see a number of the dominant baseline renderings differ.
Jakob's suggestion to use dy is the simplest and most reliable solution. I would also suggest you use values defined in em units.
1em is the height of the font glyph from the bottom of the lowest descender to the top of the highest ascender or accent.
Descenders are typically around a quarter of an em. So to raise the text above the line use dy="-0.25em". Correspondingly, to hang below the line, use dy="0.75". See the example below.
<svg width="100%" height="200">
<line y1="100" x2="100%" y2="100" stroke="grey"/>
<text x="20" y="100" font="Arial, sans-serif" font-size="40">
<tspan>Hanging</tspan>
<tspan y="100" dy="-0.25em">Hanging</tspan>
<tspan y="100" dy="0.75em">Hanging</tspan>
</text>
</svg>
The main advantage to using em units is that they are independent of the font size. So you can tweak the value to suit your font exactly, and those em values will automatically work for any font size you specify.
I ran into the same problem recently, and found a solution that worked in my case:
After trying the dominant-baseline and baseline-shift properties only to find out that both of them don't work in all browsers I'm aiming to support, a college pointed out to me that you can use the dy attribute on a <text> element to shift it after the glyphs have been positioned along a <textPath>.
Here is some pseudocode/jsx to illustrate my solution:
<g {...}>
<path
id={textPathId}
fill="none"
transform={…}
d={…}
/>
<text
textAnchor="middle"
fill={textFill}
dy={shiftText}
>
<textPath
xmlnsXlink="http://www.w3.org/1999/xlink"
xlinkHref={`#${textPathId}`}
startOffset="50%"
>
{text}
</textPath>
</text>
</g>
Notice that this depends on the knowledge of a shiftText value that has to be known or calculated independently. If this isn't given I think the only road forward is to use a combination of dominant-baseline and baseline-shift while distinguishing the browsers used.
Related
I have some text on a blue rectangle, centered horizontally and vertically. It is nearly perfectly in the center, however it is slightly too high. How can I fix this so that it is perfectly centered?
<svg width="400" height="400" xmlns="http://www.w3.org/2000/svg">
<g>
<rect fill="#8080ff" height="400" width="400" y="0" x="0"/>
<text font-weight="bold" stroke="black" x="50%" y="50%" dominant-baseline="middle" text-anchor="middle" font-family="Arial, sans-serif" font-size="24" stroke-width="0" fill="#000000">Go</text>
</g>
</svg>
Changing dominant-baseline: middle to dominant-baseline: central fixed the problem. I had to look this up but if I understand it correctly, central prioritises the ideographic baseline whereas middle prioritises the alphabetic baseline. The alphabetic baseline hugs the bottom of the text, whereas the ideographic baseline rests just below the text. This extra space also sits above the text (regardless of the baseline being used), so you have to use the ideographic baseline to accomodate for this extra space, to centre it perfectly.
I think that's how it works anyway. These are the links I used to figure it out, if you want to understand it more.
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/dominant-baseline
What is the difference between alphabetic and ideographic in Flutter's TextBaseline enum
Having used Postscript for years, I am now learning SVG. There is a feature of PS that I have not been able to replicate so far: zero-width lines. In PS, a line with zero width is always visible: PostScript converts zero line width to the smallest printable width. On the screen, when zooming they never get any thinkness, yet are visible no matter the scale. I have used them when I wanted to render very thin lines, without worring about the final resolution I was going to use, and they turned out really useful.
However, in the official SVG docs (https://www.w3.org/TR/svg-strokes/) it says that:
A zero value causes no stroke to be painted. A negative value is invalid.
Is there a way in SVG to build zero-width lines in the sense of PostScript?
As Robert said, the nearest thing to what you want in SVG is vector-effect="non-scaling-stroke". This fixes the stroke width at 1 no matter how the SVG is scaled.
This works on Chrome and Firefox (and probably Opera - haven't checked), but AFAIK not IE/Edge.
<svg viewBox="0 0 100 100">
<rect x="10" y="10" width="80" height="80"
fill="none" stroke="black" stroke-width="1"
vector-effect="non-scaling-stroke"/>
</svg>
Note that antialiasing will come into play depending on the position of the lines. The position will be affected by the scale.
If your lines are rectilinear (horizontal or vertical), you might also want to use shape-rendering="crispEdges". This will turn off antialiasing for the shape on which it is used, resulting in sharp one-pixel lines.
<svg viewBox="0 0 100 100">
<rect x="10" y="10" width="80" height="80"
fill="none" stroke="black" stroke-width="1"
vector-effect="non-scaling-stroke" shape-rendering="crispEdges"/>
</svg>
This is the only thing preventing me from understanding how the coordination system works...
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
width="600" height="400" x="0" y="0">
<text x="0" y="0">
<tspan>✉</tspan>
</text>
</svg>
If the y-axis points down why does y="0" start from the outside of the viewport? Shouldn't it start right at the top edge? It blows my logic away...
The x-axis points to the right and it starts right in the left edge of the viewport, now this is logic and normal behavior.
Why does the y-axis behave like this? Or why make one start from the outside and the other not? What is the logic behind this? Unless I'm misunderstanding how it works...
It's all in the SVG specification
the initial coordinate system has the origin at the top/left with the x-axis pointing to the right and the y-axis pointing down
The origin for text is basically the bottom left corner of the glyph for left-to-right text.
For most uses of Latin text (i.e., writing-mode:lr, text-anchor:start and alignment-baseline:baseline) the alignment-point in the glyph will be the intersection of left edge of the glyph cell (or some other glyph-specific x-axis coordinate indicating a left-side origin point) with the Latin baseline of the glyph.
default baseline is in text downside, can use attr dominant-baseline change baseline, here is mdn example
<svg viewBox="0 0 200 120" xmlns="http://www.w3.org/2000/svg">
<path d="M20,20 L180,20 M20,50 L180,50 M20,80 L180,80" stroke="grey" />
<text dominant-baseline="auto" x="30" y="20">Auto</text>
<text dominant-baseline="middle" x="30" y="50">Middle</text>
<text dominant-baseline="hanging" x="30" y="80">Hanging</text>
</svg>
I am developing a web page trying to focus on accessibility, and created different graphics in SVG to go in it. After reading different sites online (1, 2, and 3), I included the <title> and <desc> tags, and added the attributes role and aria-labelledby to make the SVGs more accessible.
Some of those sources, seem to claim (directly or indirectly) that using SVG inline is better for accessibility; so I ran a few tests with NVDA to see the differences, but I fail to see any at first sight.
For example, using a simple SVG:
<svg width="100" height="100" viewBox="0 0 100 100" role="img" aria-labelledby="title desc">
<title id="title">Abstract Forms</title>
<desc id="desc">Red square containing a white circle containing a blue triangle pointing up.</desc>
<g stroke="none" stroke-width="0">
<rect x="0" y="0" width="100" height="100" fill="red" />
<circle cx="50" cy="50" r="40" fill="white" />
<path d="M 50,20 80,70 20,70 Z" fill="blue" />
</g>
</svg>
If I add it to the page like that, NVDA reads "Graphic. Abstract Forms. Red square containing a white circle containing a blue triangle pointing up."
And if I save it into a myImg.svg file, and add it to the page like this:
<img src="myImg.svg" alt="Red square containing a white circle containing a blue triangle pointing up" title="Abstract Forms" />
NVDA then reads "Graphic. Red square containing a white circle containing a blue triangle pointing up." (same thing as before, just not reading the title).
This may be an NVDA thing, and other screen readers may do it differently, but there doesn't seem to be any considerable difference between the two. At least not to claim that inlining the SVG is better for accessibility.
Then I thought it could be related to reading additional information; for example, if there was some text within the graphic. So I added a <text x="50" y="50" fill="black">Hello World</text> at the end of the SVG... but NVDA read the same thing as before; not even selecting the text it will read it (again I don't know if this is an NVDA thing and if other screen readers do it differently).
So my questions are: what are the differences between having SVG inline or as an image? And what are the benefits (for accessibility) of having the SVG inline?
You probably already self-answered your question.
Inline-svg is interpreted as part of the html webpage. So your svg title and description are interpreted as well and read by the screen reader.
When using an ‘img‘ tag to include the svg, the file is handled like an external file (like a jpg) and so only the ‘alt‘ attribute of the img tag (= the image description) is interpreted/read by the screen reader.
I have currently no source and can't test it a the moment, but I think there are also differences for links within the svg code: Links within inline svg are read by the screenreader, links within external svg files not.
I've got an SVG element that I've created with Inkscape. I then take that SVG and put in as part of an XSL-FO stylesheet that is used to transform XML data and then passed through the IBEX renderer to create a pdf (which is usually then printed). As an example, I have elements in the svg/stylesheet that look like this (extra noise due to the Inkscape export):
<text x="114" x="278.36218" id="id1" xml:space="preserve" style="big-long-style-string-from-inkscape">
<tspan x="114" y="278.36218" id="id2" style="style-string">
<xsl:value-of select="Alias1"/>
</tspan>
</text>
My problem lies in the fact that I don't know how big this text area is going to be. For this particular one, I've got an image to the right of the text in the SVG. However, if this string is the maximum allowed number of W's, it's way too long and goes over the image. What I'd like (in a perfect world) is a way to tell it how many pixels wide I want the text block to be and then have it automatically make the text smaller until it fits in that area. If I can't do that, truncating the text would also work. As a last ditch resort, I'm going to use a fixed width font and do the string truncation myself in the XML generation, although that creates something both less usable and less pretty.
I've poked around the SVG documentation and looked into flowRegions a bit as well as paths, but neither seem to be be quite what I want (maybe they are though). If it helps, here's that style string that Inkscape generates:
"font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans"
Thanks in advance for the help.
You have text of arbitrary line length (in terms of characters) and you want to scale it to fit inside a fixed amount of space? The only way I can think of to rescale text to a fixed size is to place it inside an svg element and then scale the SVG to that size:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="100%" height="100%" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Resizing Text</title>
<defs>
<svg id="text-1" viewBox="0 0 350 20">
<text id="text-2" x="0" y="0" fill="#000" alignment-baseline="before-edge">It's the end of the world as we know it, and I feel fine!</text>
</svg>
</defs>
<rect x="500" y="100" width="200" height="40" fill="#eee" />
<use x="510" y="110" width="180" height="20" xlink:href="#text-1" />
</svg>
However, as seen above, the viewBox on the encapsulating svg element needs to be set to the width of the text, which you presumably don't know.
If you're referencing this SVG inside a user agent with scripting available (e.g. a web browser) then you could easily write a script to capture the width of the text or tspan element and set the viewBox accordingly.