DokuWiki

It's better when it's simple

User Tools

Site Tools


plugin:svgembed

This is an old revision of the document!


svgEmbed Plugin

Compatible with DokuWiki

  • 2020-07-29 "Hogfather" yes
  • 2018-04-22 "Greebo" yes
  • 2017-02-19 "Frusterick Manners" unknown
  • 2016-06-26 "Elenor Of Tsort" unknown

plugin Allows the use of the standard media syntax, but SVG files are placed with the <object> or <embed> tag, not the <img> tag

Last updated on
2020-10-13
Provides
Syntax, Helper
Repository
Source

Tagged with diagram, diagrams, image, images, media, svg

Installation

Install the plugin using the Plugin Manager and the download URL above, which points to latest version of the plugin. Refer to Plugins on how to install plugins manually.

Configuration

Under the “Configuration Settings” page in the admin panel, the plugin has a section with a few values:

Setting name Description Default value
max_svg_width Maximum width for SVG file size if no sizes are specified in the wiki page. 1024
default_width Default fall-through width of an SVG file. 300
default_height Default fall-through height of an SVG file. 150
default_print Make all SVG files in your wiki have a print button. (About printing.) False

See below for discussion about how these values interact with your SVG file for display.

Uploading SVG files via Media Manager

As of this writing, DokuWiki does not allow you to upload SVG files by default. This plugin will only embed SVG files that are uploaded to the wiki via the Media Manager for security's sake. To do this, you may need to create or edit the mime.local.conf file for your wiki by adding this line:

conf/mime.local.conf
svg     image/svg+xml

Once this line is added, you should be able to upload SVG files.

Usage

Upload an SVG (Scalable Vector Graphics) file via the Media Manager; external SVG files will not be handled by this plugin for security reasons. Once you have done that, link it as you would any other image or media file, e.g.,

{{:some:ns:myfile.svg?<Arguments>|<Title>}}

The SVG will be placed into your wiki page via an <object> or <embed> tag rather than an <img> tag. This allows for things such as elements with hyperlinks in the SVG to be clickable, etc., whereas embedding SVG as an image does not. (Note that this depends on support in your browser.)

Arguments

There are a number of arguments you can use. These include:

Formatting

When you specify a width and height for your image in your media link in the wikitext, it should do its best to render at that size, as long as the width is the same or less than the maximum set for SVG files. If it is greater than the defined maximum then it will render the SVG file with the maximum width and scale the height proportionally.

Example
{{:some:ns:myfile.svg?800x600|}}

will render the file at 800×600, although the height may vary based on requirements passed by the SVG rendering engine to keep the aspect ratio correct.

If you do not specify any size information in your media link the SVG file will be inspected to determine the dimensions (subject to scaling if above the maximum width, as above).

  • If the width and height attributes are set, then those will be used for the image. If your width or height attributes are in an absolute length unit the XHTML output will be scaled for 96 DPI (screen viewing).
  • If they are not available but the viewBox attribute is set then it will be parsed to get the dimensions.
  • If neither is available, the defaults specified in the admin panel is used.
Example
{{:some:ns:myfile.svg|}}

will render the file using the embedded dimensions, but with a maximum width configured by the admin. If the SVG file does not have dimensions in it that can be determined it will use default values specified by the admin.

If you specify only a width (as you can for an image) in your media link this actually sets a new maximum width for that embedding of the SVG file only. It will determine the size to render at from the SVG file as above.

Example
{{:some:ns:myfile.svg?2000|}}

will render the file using the embedded dimensions, but with a maximum width of 2000 pixels.

Setting "responsive" units

If you use units:<unit> as a parameter, you can call for “responsive” units for an image. This allows the SVG file to resize automatically based on the user's browser, and resize automatically. These override the normal pixels that are normally used in Dokuwiki layout. These are called in conjunction with the normal width specification for a media file.

There are two options that can be specified for the unit type:

Unit type Notes
% Percentage width. This sets the width of the SVG image to a fixed percentage of the available space.
vw Viewport units. This sets the width of the SVG image to a number of viewport units equal to the media file width specified.

This tag will use percentage width:

Example
{{:some:ns:myfile.svg?20&units:%|}}

will render the file using 20% of the width available.

This tag will use the viewport width:

Example
{{:some:ns:myfile.svg?20|units:vw}}

will render the file at 20% of the size of the viewport region width.

Additional CSS classes

You can also add additional CSS classes to your SVG file to change the style on it. You do this with class:<classname>. This parameter may be called more than once to add more than one class.

For example, to add the CSS classes redborder and bluecircle you could do the following:

Example
{{:some:ns:myfile.svg&class:redborder&class:bluecircle|}}

The SVG file isn't just an image, but rather it's another document. It's contained within the tag that embeds it into the page. As such, if you open a link in your SVG file without a target specified, it will open within the bounds of the embedded SVG document. This is by design.

If you want a link to open full-page, you should specify the target attribute on your links in your SVG file. In particular, if you specify the _top target then your links will open in the current page at the top level.

Visio produced SVG files

You can produce an SVG from Visio however it doesn't populate the title tag with anything useful so the link will just show something meaningless on hover, it is made worse if your shape is a 'group'since each item in the group will have a 'title'. The basic workflow from Visio is as follows:

In Visio:

  1. Draw and save the Visio diagram.
  2. Add hyperlinks to the shapes - this means the item (the linked to page or image) must exist on the wiki , or use a placeholder; use the full URL and populate the description field (this becomes the xlink 'title).
  3. For the given diagram select all the shapes then Save As an SVG and untick the Visio properties (can set as a general option in settings) as they simply add bulk.

In a text editor (e.g. Notepad++):

  1. If you have added hyperlinks search for 'xlink' then add a target tag (see example below), sadly It seems there is no way to force this in Visio which means you need to edit the SVG file on every revision.
  2. To solve the 'title' issue remove extraneous Alt text: find all lines with the title tag (Regex would be <title>(.*?)</title>) replace with nothing. If you don't do this then hovering over any shape will show meaningless titles like 'Sheet.235' which is no help to anyone, and removing title doesn't seem to have any untoward consequences. Note it doesn't change the xlink titles you created when entering the Description field in the hyperlinks.e
  3. Save the file.

In the Wiki:

  1. Upload
  2. Add to a page using SVGEmbed

Example and notes

  • The links must exist or be known prior to existence so that you can edit them in the Visio produced SVG file.
  • Always used the full URL in the link
  • The SVG xml code for the hyperlink will look something like this once edited:
	xlink:href="http://mysite.com/doku.php?id=ns:mypage"
	xlink:title="My Page Title"
	target="_top">

The target value of “_top” must be added to ensure that the link opens in the current page properly (or use an other target tag value).

Malformed or unusual SVG files

If your SVG file does not have dimensions specified in width and height or viewBox attributes then it can still be rendered, but scaling is handled by the browser's engine. In most cases this means that whatever dimensions are set in the wikitext or calculated by the plugin only renders a viewport on the file so it may be clipped in undesirable ways.

You may be able to fix this by loading the file into an SVG-capable editor (such as Inkscape) and setting a size or even saving the file and letting it impose one on it.

Development

Change Log

  • 2020-06-07
    • Made change to make compatible with Hogfather RC2.
  • 2020-06-05
    • Changes to fix issue #6, an enhancement request to support responsive images. I added new parameters that allows a user to set responsive (% and vw) units instead of the default px units. At the same time, I added another parameter to support adding CSS classes to the SVG image.
  • 2020-05-12
  • 2020-01-17
    • Updated to embed the SVG with an <object> tag rather than an <embed> tag, and use <embed> as a fall-through. Should support more browsers and give more options to style or extend in the future.
  • 2019-11-26
    • Changes to fix issue #3 from Github; I wasn't handling metadata rendering so the media manager didn't know if a file was in use or not. This is resolved.
  • 2019-11-25
    • Changes to fix Github issues #1 and #2.
  • 2019-07-10
    • Change to fix conflict with Imagemap plugin.
  • 2019-06-21
    • Initial release

Known Bugs and Issues

None. If you find a bug, please submit a bug at the project's github.

Discussion

Great plugin! But I have two points that could be optimized:
When printing a page with SVG file, the SVG image is greatly reduced in size.
The section edit function gets a bit confused when this section contains an SVG image.
Juergen_aus_Zuendorf 2019-11-25 16:13
I see your issues you submitted on the github page. Thanks for the heads up!

What browser are you using? Are you setting width and height on the SVG images? I don't have the problem with scaling when printing if I set a width and height on the image in Chrome or Firefox.

I have confirmed your other issue reported on github regarding flickering when you try to edit a section; that one is confusing, I'm going to have to look into that one some more. I have seen it with some other plugins and certain stylesheet alterations, too.

Michael Bowers 2019-11-25 19:11
I think these issues are fixed in my latest commit. Please update and test.
Michael Bowers 2019-11-26 01:55

One more thing: The media manager indicates that the SVG file is not in use. Therefore, there is a certain danger that it will be accidentally deleted.
Juergen_aus_Zuendorf 2019-11-26 12:54

You are a harsh taskmaster… and I appreciate it! :-)

I'll get on it when I get to the office.

Michael Bowers 2019-11-26 14:56

Fixed it in a new commit. Let me know what else you may find!

Michael Bowers 2019-11-26 22:32
plugin/svgembed.1610679125.txt.gz · Last modified: 2021-01-15 03:52 by Restless