I'm using selectPDF html to pdf converter to convert an svg document to pdf. I'm using the webkitRestricted browser engine to ensure it runs correctly on azure. Generally speaking, everything is working correctly, including using pattern definitions. I recently added the use of the patternTransform attribute with the rotate option. This does not appear to be recognized by the webkitrestricted engine and is not working. If i take the underlying html into either firefox or chrome latest versions, the patternTransform attribute does function correctly. Is there a way to overcome this issue using selectpdf ? I'm not clear which version of webkit is being called by selectpdf and whether i can control this in any fashion ?
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 need to fetch a lot of SVG documents from AWS and I use vue.js to render the content of the SVG. This works fine in Chrome, Firefox, Edge and Safari but fails without errors in IE11.
I have created jsFiddle to illustrate my issue: https://jsfiddle.net/dotnetCarpenter/pp7bcLkk/
The raw SVG file can be viewed here and is rendered in IE11: https://napp-siesta-test.s3-eu-west-1.amazonaws.com/siesta-demo-mwqxbrqx/uploads/1506688653629/viewer/472.svg
Since I need to set v-show and class on the SVG, I have a <svg> container in my template that I add the SVG string to via v-html.
I strip the <svg> element from the received SVG document and also resolve the relative paths to fonts, since I'm in-lining the SVG.
As discussed in this issue v-html uses innerHTML which has no effect on SVG element in IE.
Luckily in VueJS 2.6 there was a workaround added.
So for you there are two possible fixes: upgrade VueJS version or use custom render function and construct VNodes for SVG content manually.
Is this possible at all? I call Image.createSVG(...) and receive an Image object without any errors. I then call Button.setIcon(). But there's no icon on the button.
You need to check Image.isSVGSupported() which currently will always return false.
Back in the day J2ME supported SVG thru one of the JSR's. No platform since has supported SVG natively with the exception of the web so this doesn't work on any of the modern platforms and we didn't bother implementing this even for the JavaScript port.
In the future we'd like to have a more efficient/portable way of supporting SVG e.g.: https://github.com/codenameone/CodenameOne/issues/1890
I am using Raphael to create a dynamic visualization. Is it possible to allow the image generated on the Canvas to be downloaded as a SVG/PDF or another image format?
There are pieces of information missing here, namely browser support, server-/client-side solution and whether costs are okay or not. So I'll try to give you an exhaustive answer.
For a client-side solution, you can use DocRaptor. Just feed the SVG tree to DocRaptor This works for the SVG-producing browsers (all since 2005 except for IE prior to version 9). Note that DocRaptor has a fee for converting documents into PDF. For a free server-side solution for converting an SVG tree to a PDF, I would suggest using wkhtmltopdf as proposed in this answer.
For IE6-8, which Raphaël produces VML for, you could create a PHP solution using the Vector Converter library. When the conversion from VML to SVG is finished, sent the SVG to DocRaptor (or wkhtmltopdf).
There is no free client-side VML/SVG -> PDF solution that works for VML or SVG. To build that would mean interpreting SVG and/or VML, creating a PDF from it using JavaScript (there are JS PDF library attempts), and sending it to the client using some Flash technique. I guess nobody has attempted to build that yet. I might.
pdfkit seems to be the way to go, with using browserify to make the node code run client side. There is a nice demo here
You can save as an image using canvg and canvas2image libraries
http://code.google.com/p/canvg/
http://www.nihilogic.dk/labs/canvas2image/
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).