I want to inquire more about the problem discussed on this issue SVG Font Rendering Problems while rendering Text on a Path in Chrome and Safari
Following the example shown on http://jsfiddle.net/v6esx/4/
<path id='menu_path' d="M 80,40 Q 200,85 245,205" stroke="none" fill="black"/>
<text fill="white">
<textPath xlink:href="#menu_path">News Info Presse Musik</textPath>
</text>
On Firefox 26 (OSX) the text looks misaligned, more so if a zoom is applied. The issue is even more grave on Chrome 32 on Windows 7.
You can see some screenshots from the original question on:
http://imageshack.us/a/img18/3195/svgrendering.png
enter link description here http://imageshack.us/a/img18/3195/svgrendering.png
http://imageshack.us/a/img705/7334/svgrenderingwithpath.png
enter link description here http://imageshack.us/a/img705/7334/svgrenderingwithpath.png
As a D3.js developer, this impacts the look of some visualisations that use this technique. For instance you can notice this odd effect in http://bost.ocks.org/mike/uberdata/ specially on the "Downtown" and "Marina" labels
Screenshot 1 on windows 7 + chrome 32
Screenshot 2 on windows 7 + chrome 32
I want to bump this just to ask, does anybody knows a workaround, or are we just at the mercy of how each individual browser tries its best to render a text along a path?
To a certain degree you are dependent on the browser, but you can give the browser suggestions using the text-rendering property.
From the specs:
11.7.4 The ‘text-rendering’ property
The creator of SVG content might want to provide a hint to the implementation about what tradeoffs to make as it renders text. The ‘text-rendering’ property provides these hints.
auto
Indicates that the user agent shall make appropriate tradeoffs to balance speed, legibility and geometric precision, but with legibility given more importance than speed and geometric precision.
optimizeSpeed
Indicates that the user agent shall emphasize rendering speed over legibility and geometric precision. This option will sometimes cause the user agent to turn off text anti-aliasing.
optimizeLegibility
Indicates that the user agent shall emphasize legibility over rendering speed and geometric precision. The user agent will often choose whether to apply anti-aliasing techniques, built-in font hinting or both to produce the most legible text.
geometricPrecision
Indicates that the user agent shall emphasize geometric precision over legibility and rendering speed. This option will usually cause the user agent to suspend the use of hinting so that glyph outlines are drawn with comparable geometric precision to the rendering of path data.
For curved or transformed text, I think geometricPrecision results in the best outcomes. See live example.
Related
I'm struggling to find a way of printing a wide SVG image. This is a common problem so let me explain my specific problem.
The image is wide and so I need to tile it (poster fashion) across about 5 or 6 A4 sheets (actual count not important). My first problem is that the default Print dialog in my Firefox or Chrome browsers, under Windows, do not allow me to scale the image height to fit the page height while also spreading the image width across multiple pages.
Someone else suggested using Inkscape to convert to PDF format as the Print dialog in Acrobat reader has better support for tiling. Well, it does, but Inkscape does not deal with embedded images (e.g. PNG or JPG). Worse still, it generates huge square error markers saying "Linked image not found" all over. These are also preserved in the generated PDF which makes it useless.
There are lots of online tools that claim they can convert SVG to PDF. I tried a handful and none coped with embedded images. They were simply discarded.
So, I'm basically looking for any route to print a wide SVG image onto a horizontal series of pages, and that preserves any embedded PNG/JPG images.
[Edit]
Some of the online results:
zamzar -- images discarded
cloudconvert -- simply used inkscape
convertio -- best of the bunch, but opacity ignored on images
online-convert.com -- images discarded
pdfresizer -- simply used inkscape
freefileconvert -- simply used inkscape
onlineconvertfree -- failed with basic SVG
pdfaid -- massively failed with basic SVG
[Edit 2]
Here are a few lines of code that show one of the embedded internet-based PNG references. This one is designed to provide a faint background image underneath the subsequent SVG shapes. Hence the opacity of 12%.
<defs>
<pattern id="img2" width="50%" height="100%" >
<image xlink:href="https://clipartart.com/images/tree-branch-clipart-png-4.png" x="0" y="0" width="50%" height="100%" />
</pattern>
</defs>
<rect width="100%" height="100%" fill="url(#img2)" fill-opacity="0.12" />
I've had time to experiment with this further (and so wasting printer paper by the shed-load).
1) Inkscape deliberately does not support Internet image references (e.g. http) for "security reasons". As mentioned, it puts a horrible error marker in the view of the loaded SVG and I have found no way to edit it out. Hence, it gets saved in any PDF version.
2) If I download local copies of the images and change their http:// references to equivalent file:/// (yes, 3 slashes) then they are accepted.
3) This allows a PDF copy to be saved, but if any of the images had an opacity (e.g. a background image) then that gets lost and it is full opacity in the PDF. This may be a conversion issue or a PDF limitation -- I do not know.
4) Since I then have local copies of the images, they can be changed to implement any faintness required "at source".
5) The Acrobat Print dialog has a Poster option for tiling the pages of a wide image. Ensuring no 'cut marks' or 'labels' are added, you can set a 'Tile scale' that keeps the height within one page, and it will spread it over as many pages as necessary for the width. On the basis of the scaling, it selects landscape/portrait itself and ignores any selection of your own.
So, problems? Yes, the Acrobat 'Overlap' setting is a mystery, leaving a thin white margin on either one or both of adjoining sheets in the output. I have not been able to correlate the width of this margin, or the appearance on one or both sheets, with this setting.
Via the Preferences button, I can get to the normal printer preferences dialog, where I can request 'Borderless printing'. Rather than fixing the issue, this just makes the correlations even more mysterious.
I'm trying to improve a Lighthouse accessibility score and know how to address everything it's throwing at me except for one thing.
I have a colour contrast issue whereby I have used a Unicode ★ character for some ratings. It's coloured yellow (#FFD500), but contrast against white background fails AA. I cannot change the colour, but I have provided a text-based alternative (using off-screen positioning) for screen readers. So completely blind people using assistive tech are covered, but I really cannot think how to resolve the low contrast issue for sighted users. I thought to use aria-hidden="true" to stop Lighthouse from assessing it, didn't work.
I can't change colour, I can't change the size, I can't mask it in the report. I guess there's nothing I can do?
Note that I can change the unicode star for an image/svg. This will resolve the issue but for various boring reasons I won't go into, this approach caused other issues (and was what made me opt for unicode characters).
Stopping Lighthouse from assessing something doesn't make it compliant, and aria-hidden="true" hides content from screen readers, but color contrast is an issue for low-vision users, not blind users.
Technically, the color contrast ratio you've got (1.42:1) is too low for any size.
If you absolutely cannot adjust this color, then my recommendation would be to include a text-based alternative nearby, eg:
★ ★ ★ ★
4/5
#j-afarian has a nice idea with the text-based rating ("4/5") in addition to the stars, but if the stars are still yellow, it still fails WCAG 1.4.3. However, 1.4.3 only deals with text color contrast. Since you are using unicode, which is essentially text, it's fair game for 1.4.3.
But if you swap out the unicode for an svg or image, as you mentioned, there is no color contrast failure because it's no longer text. It will still be a problem for low vision users but is not a WCAG failure. That's kind of gaming the system and defeats the purpose of WCAG, but technically it's not a WCAG failure.
I would love to know the "various boring reasons" that caused the problem with svg/img. We can resolve those too.
If you can't change the (foreground) color of the unicode stars, can you change the background color?
<span style="color:yellow">★ ★
<!-- 4.55 color ratio with gray background -->
<span style="background-color:#717171">★ ★</span>
<!-- 8.00 color ratio with blue background -->
<span style="background-color:#0000FF">★ ★</span>
<!-- 4.51 color ratio with red background -->
<span style="background-color:#E50000">★ ★</span>
</span>
I've been working on a charting library using d3 and SVG to display a series of rectangles. The dataset governs the number of rectangles to be displayed in a given area, and in most cases, the math doesn't work out cleanly, meaning the rectangles don't start and end on whole numbers. Firefox, Chrome and Safari all address this contingency by antialiasing the rectangles. IE seems to just round to the nearest pixel value, and refuses to antialias any rect elements. I've tried changing shape-rendering and the like, to no avail.
Here's a side-by-side comparison of the same data in IE10 and the most recent Chrome release:
IE10:
Chrome:
Is anyone aware of a fix for this that doesn't involve changing the structure of the SVG markup? Setting CSS properties or tag attributes is preferable to changing the elements themselves. Barring that, has anyone seen any Microsoft documentation explaining the rationale for this decision? I haven't been able to turn up any thus far.
IE doesn't seem to care about the shape-rendering property, but I've found that you can force it to anti-alias shapes by specifying a tiny rotate transformation:
svg {
transform: rotate(.00001deg); /* hack to force anti-aliasing in IE */
}
Tested on IE11.
I've a web page in which there is a SVG box <svg id='graph'>...</svg>.
I would like to give to the user the possibility to zoom in the SVG box.
I use for this purpose document.getElementById("graph").currentScale*=2; if I want to double the size of the box, for example.
The problem is that all the window is resized, even the HTML elements outside the box.
Do you know the origin of this problem please ?
In order to apply zoom to only svg , use this...
<svg>
<g transform="scale(2)">
</g>
</svg>
This may be off the mark without knowing which browser you're using, but you may not be able to implement currentScale if you're using anything other than Internet Explorer or Microsoft Edge. You can test this for yourself by trying this JSBin in different browsers and see where it scales.
Diving into this deeper, a Google search of "SVG currentScale" found these bug threads from Google and Mozilla discussing similar issues. The Mozilla thread discusses it was a choice made specifically for consistency's sake. SVG's currentScale only applies to container elements and not to inner elements. This could interfere with functions like zoomAndPan used on inner SVG elements. Additionally, better cross-browser solutions are already in place such as scale() via the transform property.
Does anyone know if there is a workaround for this? Internet Explorer 10 and Window phone 8 are not able to correctly scale background SVG images when a user zooms. Looks like IE rasterizes the SVG on load.
Here is an example: The first image is the SVG as a background image. Zoom in on a MS Surface or Windows 8 phone and you'll see it blurs horribly.
The second image is the same SVG as an img tag. Zoom this on a Surface or Windows 8 mobile phone and it scales as you would expect (nice and clean).
Is there any property that can be added to make IE10 behave? Or is it merely a case of waiting for the folks at Redmond to fix it?
The problem is that IE, and other browsers such as Firefox rasterise the SVG before displaying it, so it will become blocky when zoomed.
The easiest way to fix this is to make the SVG file larger than is needed. For example double the size, or more if the user is likely to zoom in further. You can then resize the SVG image with CSS to display it at the correct size. This way the image will be naturally larger, so wont become blocky, unless you zoom in even further. At default zoom level the image is scaled down rather than up, which browsers usually handle better.
Edit: You can find further info on this issue under the “SVG and CSS Backgrounds” heading at http://dbushell.com/2012/03/11/svg-all-fun-and-games/