Fontastic.me is a website that let you upload svg files so you can use your icons as a font. I've used this site lots of times, but today I noticed the icons are not working on mobile anymore. They do work in the browsers on computer. I only noticed it today, it has always worked before.
You can use this link to test on mobile.
To me it seems like a bug in the Fontastic CSS generator: your page links CSS
https://fontastic.s3.amazonaws.com/8pMGtiqubDqmpbD4ER7hE3/icons.css
this contains last SVG fallback linked as
https://cdn.myfontastic.com/8pMGtiqubDqmpbD4ER7hE3/fonts/1446830181.svg#1446830181
the hash part of the URL must correspond with font ID in the SVG, but actual source contains <font id="cloud-font" horiz-adv-x="512"> instead.
So replacing #14468301 with #cloud-font in CSS or replacing #id value in SVG should fix your problem.
This applies only for case your mobile really resorts to SVG version. Only few browsers would do that (I think Android below 4.4, maybe old Safari, Blackberry, and maybe Opera Mobile).
(Besides that, your HTML contains extra HEAD tag with icon CSS link in BODY, what is not valid. I donʼt think this will make any sane browser completely ignore the link, but cannot exclude such possibility. If you have served your page as real application/xhtml+xml, browser should show the error right away.)
Greg, i had the same issue. I end up ditching Fontastic and use https://glyphter.com/ instead.
Glyphter creates your own font set by uploading each character at a time.
It worked for me and perhaps you can try this too and see if it works.
Related
On my TYPO3 v10 website I have some SVG icons in use, no problem.
I also have a few more complex SVG Figures (created with Inkscape), that I want to include in TYPO3 website. Of course I can upload the .svg files to the fileadmin/ folder, and link to them with the Text+Image (or Text+Media) Content Elements.
In the Backend, TYPO3 generates some fine png-thumbnails for preview. So far so good.
The file can be downloaded directly, from its fileadmin/images ... location.
However, inside web pages, my SVGs are not displayed as they should.
A lot of styling information gets removed from the SVG and I don't know where.
Here is a screenshot of the original vs corrupted image (as displayed in the TYPO3 frontend).
Here is a graphical diff that shows the difference between the figures.
It turns out that at some time during the rendering process, TYPO3 removes the values from the style="...." SVG attributes. See reddish boxes.
All my more complex SVGs look like the one on the right when embedded in TYPO3.
Here is the SVG if you want to try yourself: image on SVGshare.com
On the right, many style attributes have been set to style="".
but why?
It's Firefox, not TYPO3, who removes the style="..." attribute values. This seems to be a longstanding Firefox Issue, solved.
See Bugzilla Issue 1262842: [CSP] Blocks the use of style attributes inside SVG without generating console errors.
Look for "triply confusing" in the first comment.
Inline CSS styles can be a security Problem, and therefore Firefox has a Content-Security-Policy (CSP) in place, in order to correct this.
An explainer for the mitigation strategies, written jointly by professional Security Engineers is given in this Google Doc and in Gihub Repo (Content Security Policy), Issue 45, Further granularity of unsafe-inline styles.
Script inline attributes are a difficult subject to approach when it
comes to CSP, they have the same amount of power as any other script
element but they don’t have ways to be whitelisted, for example, by a
nonce or hash. This means that the actual content of the attribute is
mostly the only deciding factor.
I don't understand everything mentioned in these docs and discussions. Inline-style Elements seem to be vulnerable to XSS attacks, and then attacker can put CSS url() in there for instance.
Quick-and-dirty solution
Use Inkscape and save as "optimized SVG", and check the option "Convert CSS Attributes to XML attributes". See attached screenshot of the Inkscape Dialog (Linux).
This solution was proposed by a web-developer from the GIMP devteam.
TYPO3 9 introduced an SVG Sanitizer, which automatically modifies SVG files during "fileadmin upload time", meaning it removes any <style ...> elements from the uploaded SVG file.
In TYPO3 10 and later versions, this SVG Sanitizer is by default automatically set up via Symfony dependency injection via core's Services.yaml.
You can remove the SVG Sanitizer via your own site extension's Services.yaml, e.g. for your myextension/Configuration/Services.yaml:
services:
_defaults:
autowire: true
autoconfigure: true
public: false
# ...
# remove TYPO3's default-autowired SvgSanitizer, which tampers with filadmin uploaded SVGs (e.g. removes necessary <style> information)'
TYPO3\CMS\Core\Resource\Security\SvgEventListener: ~
The tilde (~) removes/overwrites the definition previously set up by core's Services.yaml ( https://symfony.com/doc/current/service_container/service_decoration.html ).
This seems to be a problem of your individual TYPO3 installation. I've just tested your SVG image in a brand new TYPO3 v10 installation and the image is rendered properly in backend and frontend.
Maybe you have some 3rd party extensions installed who postprocess the HTML output of TYPO3, e.g EXT:sourceopt or EXT:scriptmerger.
I've setup two pages with the background-size:cover; with one using a .jpg and one using a .png. Both pages render fine in Chrome/Safari/Firefox on the desktop, but for some reason the .jpg version does not render on iPhone/iPad in Chrome/Safari.
PNG Version
JPG Version
I suspect it might have something to do with the compression of the .jpg which I set to the lowest (smallest file size) setting in Photoshop, but I could not find any actual info on this. Any advice is much appreciated!
EDIT:
I am already using the browser specific prefixes in my css (e.g. -webkit-,-moz,-o-).
background-size is a new CSS property and therefore isn't available everywhere yet
although in mobile devices -webkit-background-size:cover; should do the trick
For Safari versions <5.1 the css3 property background-size doesn't work. In such cases you need webkit.
So you need to use -webkit-background-size attribute to specify the background-size.
Hence use -webkit-background-size:cover.
Reference-Safari versions using webkit
I know that an image can be placed in an MD with the MD syntax of either  or , but I am having difficulty placing an SVG in MD where the code is hosted on GitHub.
Ultimately using rails3, and changing the model frequently right now, so I am using RailRoady to generate an SVG of the schema diagram of the models. I would like for that SVG to then be placed in the ReadMe.md, and be displayed. When I open the SVG file locally, it does work, so how do I get the browser to render the SVG in the MD file? Given that the code will be dynamic until it is finalized (seemingly never), hosting the SVG in a separate place seems overkill and that I am missing an approach to accomplish this.
The SVG I am trying to include is here on GitHub: https://github.com/specialorange/FDXCM/blob/master/Rails/fdxcm/doc/models_brief.svg
I have tried the following, with an actual image as well to verify the syntax is working, just that the SVG code isn't being rendered:
![Overview][1]
[1]: https://github.com/specialorange/FDXCM/blob/master/doc/controllers_brief.svg "Overview"
<img src="https://raw.github.com/specialorange/FDXCM/master/doc/controllers_brief.svg">
[Google Doc](https://docs.google.com/drawings/d/1B95ajItJTAImL2WXISX0fkBLYk3nldea4Vm9eo-VyE4/edit) :
<img src="https://docs.google.com/drawings/pub?id=117XsJ1kDyaY-n8AdPS3_8jTgMyITqaoT3-ah_BSc9YQ&w=960&h=720">
<img src="https://raw.github.com/specialorange/FDXCM/master/doc/controllers_brief.svg">
<img src="https://docs.google.com/drawings/d/1B95ajItJTAImL2WXISX0fkBLYk3nldea4Vm9eo-VyE4/edit">
to get the results of:
1: https://github.com/specialorange/FDXCM/blob/master/Rails/fdxcm/doc/controllers_brief.svg "Overview"
Google Doc :
The purpose of raw.github.com is to allow users to view the contents of a file, so for text based files this means (for certain content types) you can get the wrong headers and things break in the browser.
When this question was asked (in 2012) SVGs didn't work. Since then Github has implemented various improvements. Now (at least for SVG), the correct Content-Type headers are sent.
Examples
All of the ways stated below will work.
I copied the SVG image from the question to a repo on github in order to create the examples below
Linking to files using relative paths (Works, but obviously only on github.com / github.io)
Code
<img src="./controllers_brief.svg">
Result
See the working example on github.com.
Linking to RAW files
Code
<img src="https://raw.github.com/potherca-blog/StackOverflow/master/question.13808020.include-an-svg-hosted-on-github-in-markdown/controllers_brief.svg">
Result
Linking to RAW files using ?sanitize=true
Code
<img src="https://raw.github.com/potherca-blog/StackOverflow/master/question.13808020.include-an-svg-hosted-on-github-in-markdown/controllers_brief.svg?sanitize=true">
Result
Linking to files hosted on github.io
Code
<img src="https://potherca-blog.github.io/StackOverflow/question.13808020.include-an-svg-hosted-on-github-in-markdown/controllers_brief.svg">
Result
Some comments regarding changes that happened along the way:
Github has implemented a feature which makes it possible for SVG's to be used with the Markdown image syntax. The SVG image will be sanitized and displayed with the correct HTTP header. Certain tags (like <script>) are removed.
To view the sanitized SVG or to achieve this effect from other places (i.e. from markdown files not hosted in repos on http://github.com/) simply append ?sanitize=true to the SVG's raw URL.
As stated by AdamKatz in the comments, using a source other than github.io can introduce potentially privacy and security risks. See the answer by CiroSantilli and the answer by DavidChambers for more details.
The issue to resolve this was opened on Github on October 13th 2015 and was resolved on August 31th 2017
I contacted GitHub to say that github.io-hosted SVGs are no longer displayed in GitHub READMEs. I received this reply:
We have had to disable svg image rendering on GitHub.com due to potential cross site scripting vulnerabilities.
Update 2020: how they made it work while avoiding XSS attacks
GitHub appears to use two security approaches, this is a good article: https://digi.ninja/blog/svg_xss.php see also: https://security.stackexchange.com/questions/148507/how-to-prevent-xss-in-svg-file-upload
show SVG inside <img tag, which prevents scripts from running, e.g. on READMEs: https://github.com/cirosantilli/test-git-web-interface/tree/8e394cdb012cba4bcf55ebdb89f36872b4c6c12a
use Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox. This prevents the script from running even in raw which contains the raw SVG file: https://raw.githubusercontent.com/cirosantilli/test-git-web-interface/8e394cdb012cba4bcf55ebdb89f36872b4c6c12a/svg-foreignObject.svg
You can see the header with curl -vvv. The regular github.com pages also have a content-security-policy, but it is much larger.
Update 2017
A GitHub dev is currently looking into this: https://github.com/github/markup/issues/556#issuecomment-306103203
Update 2014-12: GitHub now renders SVG on blob show, so I don't see any reason why not to render on README renderings:
https://github.com/blog/1902-svg-viewing-diffing
https://github.com/cirosantilli/test/blob/2144a93333be144152e8b0d4144b77b211afce63/svg.svg
Also note that that SVG does have an XSS attempt but it does not run: https://raw.githubusercontent.com/cirosantilli/test/2144a93333be144152e8b0d4144b77b211afce63/svg.svg
The billion laugh SVG does make Firefox 44 Freeze, but Chromium 48 is OK: https://github.com/cirosantilli/web-cheat/blob/master/svg-billion-laughs.svg
Petah mentioned that blobs are fine because the SVG is inside an iframe.
Possible rationale for GitHub not serving SVG images
general XML vulnerabilities. E.g. opening a billion laughs exploit just made Firefox crash my system. Firefox bug with exploit attached: https://bugzilla.mozilla.org/page.cgi?id=voting/user.html. Same on Chromium: https://code.google.com/p/chromium/issues/detail?id=231562
SVG XSS scripting: while most browsers don't run scripts when the SVG is embedded with img, it seems that this is not required by the standards, so maybe GitHub is playing it safe.
Browsers do run it if you open the SVG directly (but it appears that GitHub never shows images directly on the github.com domain) or if it is inline (which are currently completely removed by GitHub), so those cases shouldn't be a security concern. Relevant links:
spec: http://www.w3.org/TR/SVG/script.html
interactive SVG demo: http://www.w3.org/TR/SVG/images/script/script01.svg
The following questions asks about the risks of SVG in general: https://security.stackexchange.com/questions/11384/exploits-or-other-security-risks-with-svg-upload
rawgit.com solves this problem nicely. For each request, it retrieves the appropriate document from GitHub and, crucially, serves it with the correct Content-Type header.
Since Jan. 2022, that seems possible (and easy):
Allow to upload .svg files to Markdown
It is now possible to upload .svg files to comments in issues, PRs, discussions, and Markdown files, like READMEs.
You just have to drag and drop the file in the text area.
This will work. Link to your SVG using the following pattern:
https://cdn.rawgit.com/<repo-owner>/<repo>/<branch>/path/to.svg
The downside is hardcoding the owner and repo in the path, meaning the svg will break if either of those are renamed.
I have a working example with an img-tag, but your images won't display.
The difference I see is the content-type.
I checked the github image from your post (the google doc images don't load at all because of connection failures). The image from github is delivered as content-type: text/plain, which won't get rendered as an image by your browser.
The correct content-type value for svg is image/svg+xml. So you have to make sure that svg files set the correct mime type, but that's a server issue.
Try it with http://svg.tutorial.aptico.de/grafik_svg/dummy3.svg and don't forget to specify width and height in the tag.
Just like this worked for me on Github.
or
<img src="ImageAddressOnGitHub.svg">
In addition to regular SVGs, you can also insert animated SVG images in the markdown file like any other format. It can be a good alternative to GIF images.
Use relative links if both your animated SVG and your markdown file are in the same GitHub repository:
OR
<img src="relative/path/in/repository/to/image.svg" width="128"/>
Example (assuming the image is in assets directory in the repository):
Result:
Use this site: https://rawgit.com , it works for me as I don't have permission issue with the svg file.
Please pay attention that RawGit is not a service of github, as mentioned in Rawgit FAQ :
RawGit is not associated with GitHub in any way. Please don't contact GitHub asking for help with RawGit
Enter the url of svg you need, such as :
https://github.com/sel-fish/redis-experiments/blob/master/dat/memDistrib-jemalloc-4.0.3.svg
Then, you can get the url bellow which can be used to display:
https://cdn.rawgit.com/sel-fish/redis-experiments/master/dat/memDistrib-jemalloc-4.0.3.svg
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?
I made the following observation:
If I create an svg image that references an external raster image via xlink:href and try to load the svg in browsers, the external images are only shown if I use the <object> tag, but not when using the <img> tag.
Rendering with the <object> tag is quite slow and not as clean as using the img tag for images so I was wondering if there's a way to make it work through the <img> tag.
At first I thought it doesn't work because of a same origin policy, but even if the referenced image is in the same directory and I reference it through its name only, it wont load.
Any ideas?
Are you using IE? IE doesnt recognize SVG anyway. Microsoft is always ten years behind, yet they are more popular and far more costly, for some reason. Name brand propaganda?
SVG loads in Firefox. Both as an XML document referenced directly in the URL, and also if you embed it into an XHTML (fully XML compliant) document with proper namespacing, the SVG should render properly. The great thing about this option is that DHTML can manipulate your SVG. Everything I said in this paragraph also applies to MathML, if youre curious.
Aside from that, SVG doesn't load from an image tag. I do believe Firefox is working on this upgrade, though. Im not entirely sure.
Using the object or embed tag is reasonable, I suppose... but one of my earlier fixes was to use an iframe. Embed an iframe in your html that references the complete SVG file. Using CSS you can make the iframe look flush with the rest of your document, appearing and acting like an image. Encased in a div or span tag, you can have onhover and onclick event handlers.
Using the image tag, your src can be a PHP file on server side. If properly coded and with the appropriate cgi apps, you can rasterize your SVG on server-side, and have that PNG data sent back to your image via the PHP src.
There's no particular reason <object> should be any slower to load than <img> apart from possibly the interaction aspect (img's are static while object's are fully interactive documents). The images inside the svg should load in both scenarios, so it sounds like a bug in the browser.
Could you post a link to your example?
I think you are at least 10 months behind...IE9 supports SVG, and pre-release versions (including a beta) have been out for quite a while. Check out www.ietestdrive.com to grab the platform preview - it's pretty good. In my opinion, parts of their SVG support are much better than Firefox currently (but they don't support SMIL yet).