By ezaloga on

In our quest to find a dependable technique to use SVG’s and PNG’s in our Drupal sites, we’ve experimented with the following approaches:



Our First Approach:

Upload SVG as file, and upload PNG as image. Use fallback javascript for image replacement

Experiment:
1. Since there is no way to upload an SVG as an image type by default in Drupal, we created a file upload of an SVG image in a content type, with a separate PNG image upload. Both SVG and PNG files with matching names (except extensions) were then added to the site’s default image directory.

2. To display the SVG (for SVG compatible browsers), we created a corresponding node.tpl.php file and printed out the file in an image tag.

3. As a fallback, to display the PNG (for browsers that aren’t SVG compatible), we used a javascript solution, SVGeezy (http://benhowdle.im/svgeezy/), which displayed the PNG image version.

The Good Results:
• SVG files displayed fine in compatible browsers
• PNG files displayed fine in non-compatible browsers

The Bad Results:
• The browser has to access the database multiple times to retrieve a lot of SVG files. Assuming this slows down page load time.
• No known way to have PNG images not download when a page is loaded (if not needed). Assuming this slows down page load time.
• An extra module, Upload Replace (https://drupal.org/project/upload_replace), needed to be added to allow for replacement of SVG files after their initial upload. Adding extra time and precautions for our team members to change and swap content.

Our Second Approach:

Embed SVG code into a content type

Experiment:
1. Instead of a file upload we installed/used the SVG Embed module (https://drupal.org/project/svg_embed).
2. Then we created a text field into a content type, where we entered the SVG code.

The Good Results:
• SVG code displays fine in compatible browsers
• SVG code is embedded in the content type rather than uploaded as a file.
• SVG cannot easily be taken from website and used without permission.

The Bad Results:
• Unclear how to do PNG fallback. Since there is no SVG file being uploaded, there’s no way to use a solution like SVGeezy to provide fallback.

Our Ideal Approach:

Unknown

The Hope:
• Be able to upload SVG (and/or SVGZ) into a content type as an image type.
• Rather than PNG fallback method, instead be able to determine if the user/browser can display SVG images, and if so have browser not download PNG Images.

Additional question
Does anyone know why Pantheon servers are unable to decompress SVG compressed files (SVGZ file)? We asked them, and they mentioned they are working on it. What does a server need to have in order to do this? This could change our course of action.

Please let us know if you have any experience or insights that would help us find an ideal approach. Thanks!

⋅ Categories: Drupal 7.x

Comments

doostinharrell’s picture

doostinharrell commented

All of the tools are available to do this however there is currently no Drupal module that offers this functionality out of the box. Hence, someone would have to create a this module from scratch.

The custom module would need to include the following features:

  • Modernizer.js support
  • Custom SVG field upload (would need respective svg and png public and private folder settings)
  • Linux Image conversion app integration (maybe run on cron or call function when cck field data is saved???)

You could use Modernizer.js to reduce http requests allowing supported browsers to only download svg while unsupported browsers would default to png.

You could also call a Linux application like inkscape or imagemagick within a Drupal module to automatically create png versions of the svg images. http://inkscape.org/doc/inkscape-man.html --- http://www.imagemagick.org/script/index.php

For the meantime you could setup modernizer and inkscape/imagemagic then write a linux shell script to convert svg files in one directory to png's in another. Or you could just manually create each file.

I wish I had the time to develop this. Sounds like a very challenging yet rewarding project.

ezaloga’s picture

ezaloga commented

Looks like all SVG and no fallback is where we settled. Before we know it, SVG compatibility will be fully baked into all browsers (is mostly now anyway). I appreciate your help.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

You said:

The Bad Results:
• Unclear how to do PNG fallback. Since there is no SVG file being uploaded, there’s no way to use a solution like SVGeezy to provide fallback.

You can actually embed the png fallback with an <img> tag *inside* the SVG file itself leveraging the <switch> and tags. The image tag can either reference an external png file, OR you could use data URI, although beware that ie6 and ie7 dont support this. Also be sure to wrap the contents of your file SVG in a <g> tag (as indicated in example below).

<svg ...>
   	<switch>
   		<g>
   		   	<path .../>
   		   	<path .../>
   		</g>
   		<foreignObject>
			<img src="logo.png"/>
		</foreignObject>
   	</switch>
</svg>

Source: http://thoughtfulweb.co.uk/thoughts/about/the-best-way-to-add-an-svg-ima...