EVE
Partially updated August 17, 2003. Wow! realtime SVG code generation and customisation Export color morphing and 3D border effects to SVG
This page is an extension of the main EVE User Manual.
The concept of EVE WE is introduced here.
Preamble Inserting an SVG graphic embedded in a HTML page Server mime type How to export an EVE diagram to SVG Exporting text Exporting HTML labels Exporting icons Link activation Animation of elements Color morphing and 3D effects Realtime SVG code generation and customisation INI file customisation How to import an SVG file to EVE Browser compatibility with SVG HTML editors
Almost anything that you can draw on an EVE diagram can export to SVG vector graphic format. And then be viewed in a Web browser. This SVG graphic illustrates (Adobe SVG Viewer or equivalent required):
Here is the original EVE datafile:
svgdemo4.eve Right-click to save locally on your PC.
Note that the above embedded SVG file does not have the small face bitmap as part of the file. It is a separate file, and was extracted from EVE when the export-to-SVG operation was performed.
This is the HTML code that is inserted into this page:
<embed src="../animate4.svg" width="361" height="281" vspace="0" hspace="0" border="0" type="image/svg+xml" pluginspage="http://www.adobe.com/svg/viewer/install/" />
This can be simplified:
<embed src="../animate4.svg" width="361" height="281" type="image/svg+xml" />
And it can be simplified again:
<embed src="../animate4.svg" width="361" height="281" />
This last, simplest version should work, but it is dependent on your website's HTTP server being configured with the correct mime type for SVG. This topic is dealt with below.
Note that Namo WebEditor does not put a trailing slash, and removes it if you try and put it into the HTML source code, but this still works:
<embed src="../animate4.svg" width="361" height="281" >
The W3C specification states that the standard "img" tag for inserting images should also work, but this seems to be not implemented for now, with Internet Explorer/Adobe SVG Viewer combination. I think maybe we can look forward to this when SVG gets built-in to the browser (ie., not a plugin).
Actually, the <embed> tag is not an official standard, and it is preferable to use <object>. However, some browsers do not understand <object>. Internet Explorer (after version 4 I think) does. If you really want to be clever, you can put both in:
<object data="../animate4.svg" width="361" height="281" type="image/svg+xml"> <embed src="../animate4.svg" width="361" height="281" type="image/svg+xml" /></object>
What happens here, is that a browser such as IE will use the <object> tag, but browsers that do not understand <object> will look at what is between:
<object first choice here > alternative in here </object>
That is, will use the <embed> tag.
Something interesting came up at the www.svg-cafe.com discussion forum. A guy known only as "Richard" contributed this gem:
Hi, There is no reason why IE wouldn't work with IFrame, so why use object? Adobe advised against using <object> in IE as there were stability issues. They advised using <embed>, even if it is depreceated. On the other hand, <IFrame> works perfectly alright in all IE's from IE4 to IE6 as well. The reason I suggest using an <embed> nested inside the <iframe> is to allow for legacy NS4 support. So if you only want to support IE and Mozilla, this should work just fine: <iframe src="svgtest.svgz" width="200px" height="200px" frameborder="0" marginwidth="0" marginheight="0" > No sniffing needed. If you want to support NS4 as well, without affecting Mozilla or IE, as they don't parse the nested <embed> tag, do this: <iframe src="svgtest.svgz" width="200px" height="200px" frameborder="0" marginwidth="0" marginheight="0" > <embed src="svgtest.svgz" width="200px" height="200px" /></iframe> Still no sniffing neded. Of course, if you're generating your page in PHP anyway, you can just as well server the correct tag, like you suggest, but I think you should be serving the embed tag for NS4, and the IFrame tag for all others. Cheers, Richard.
<iframe src="svgtest.svgz" width="200px" height="200px" frameborder="0" marginwidth="0" marginheight="0" >
<iframe src="svgtest.svgz" width="200px" height="200px" frameborder="0" marginwidth="0" marginheight="0" > <embed src="svgtest.svgz" width="200px" height="200px" /></iframe>
Please note that you can view an SVG graphic "standalone". That is, if inside Internet Explorer select "File/Open..." and find the file "animate4.svg" and open it, it will appear immediately in a window.
There is an interesting comment that can be made here about paths. You will see in the above HTML code that I specified "../animate4.svg" as the location of the file, the "../" meaning that it is "one up", i.e., in the parent folder. The parent folder also has animate41.gif, the little goggly-eyed face, that EVE exported along with the SVG file. If you examine the animate4.svg file source code, you'll see that the link to the face is simply "animate41.gif", i.e., in the same folder. What I'm getting at here is that this is a complete non-issue. You don't have to worry that the goggly-face isn't in the current directory, because the SVG viewer looks for it relative to the SVG file, not this current page. Just always keep animate4.svg and animate41.gif together, and you'll be right.
As an SVG file can be viewed standalone by a web browser such as IE, there is no reason why ".svg" files can't be complete web pages. In fact, EVE can be used as a visual free-layout (also known as pixel-layout) web page design tool. Throw away FrontPage!
To insert an SVG graphic, instead of going down to the HTML source code, Namo allows it to be done via the menu.
To insert an SVG graphic, instead of going down to the HTML source code, Frontpage allows it to be done via the menu.
The above sections show "type="image/svg+xml"" being included in the "embed" or "object" tags. However, this should not be necessary.
Your web pages are hosted by a site that will be running a HTTP server. Whenever someone types a URL to one of your pages in their browser address box, your host's HTTP server will respond and download the page to the browser. The HTTP server tells the browser what type of file it is serving -- for example, a GIF graphic, plain text, or HTML page.
This file type is called the mime type. As SVG is a relatively new standard, the administrators of some hosts have not configured the correct mime type for SVG graphic files. This means that the server will download them as plain text, rather than "image/svg+xml". In such as case, you need the "type=" entry in your source code.
Wouldn't have a clue what mime type your server serves? Well, you can find out what mime type your HTTP server is serving for any file. Go to this URL:
http://www.rubynewbies.com/~tobi/mime.rb
The page has a box, into which you can type a URL -- type in a URL directly to an SVG file on your site.
If you discover that your server is serving SVG files as plain text, it is easy to configure the HTTP server correctly. Contact your host's administrator and ask for it to be done. In the case of the Apache HTTP server, the administrator will have to add these lines into the mime types configuration file (probably it is "/etc/apache/mime.types"):
AddType image/svg+xml .svgAddType image/svg+xml .svgz
However, if your HTTP server is Apache, you may be able to do it yourself. In your site's root directory, create a file called ".htacess" and put those two lines in it. You can create this on your own PC and upload using FTP, remembering if you have a Windows machine to upload using "ASCII" transfer mode. This will configure whatever directory the ".htacess" file is in plus any sub-directories. It won't configure other people's websites on the same server -- for that, the system administrator is required.
If your host doesn't have Apache, you'll need to contact the system administrator. If your host is running on a Windows OS, not Linux or Unix .... tsk, tsk ... consider changing. I use www.arrowweb.net, inexpensive, reliable, runs Apache on Red Hat Linux. Another one that looks good is www.hostdepartment.com -- their $5/month "Red Hat Linux Express" deal looks good also. The cheapest deals all use Linux, simply because it's free. Also, it's open, stable, and heavily documented, which is what you want of your host.
So what if the server serves SVG files as plain text? With standards-compliant browsers (IE isn't), the SVG source code only will display, not the actual graphic. Or, you'll just see an empty space.
Note that Amaya v.6.1 has a bug -- it ignores the "type=" entry in the "embed" tag, so you must have the server configured correctly.
This section describes the original SVG export technique, and is a good place to start. Further down, you will find another heading, "How to export an EVE diagram to SVG, take-2", which is a different approach, suited to large diagrams.
This is quite a small manual, because it's so simple.
The dialog box of Step 3, looks like this:
Note that the EVE User Manual describes the procedure of selecting "Control/Selection rectangle" from the menu, to draw a selection rectangle on the diagram. However, this is optional -- if you simply press the left button on the diagram and start dragging, EVE will automatically understand what you want, and a selection box will appear and will track the pointer.
EVE automatically calculates the final size of the graphic, such that it will display in a web page at nominally the same size you see it inside EVE. As you can see above, the size is in pixels, but you can change that to inches or centimetres.
An extra note here. The size shown above in pixels will only display the same size on other monitors if they have the same number of pixels/inch. This is ok if you're not too fussed about the size being exactly right, but if you really want the image to display close to the same size regardless of monitor settings, then choose units of inches or centimetres. Normally though, I recommend that you stay with 100% scaling and pixel output, as the SVG viewer doesn't have to do as much fancy transformations on the element coordinates to get them to fit the final box size.
You can also put margins on the sides if required, and scale the image up or down (the horizontal and vertical can scale independently).
For any changes that you make, you then need to press the "Recalculate final width and height" to get a preview of the final image size (in the two boxes marked "Width" and "Height").
I suggest that you make a note of those width and height figures, to enter them into the HTML code as shown in the previous section.
An interesting point about those margins: elements can extend into them. Before EVE composes the SVG file, she analyses each element and works out a bounding rectangle that will encompass all elements, and calculates the width and height as shown in the above graphic. However, there is the (remote) possibility that some element may in fact draw slightly outside that boundary. In that case, it will get truncated. I got this once, when a word did not wrap onto the next line as expected, so was outside the boundary of the text label. As this label was on the right side of the graphic, the word got truncated. I don't think that anyone is going to encounter this problem, but just in case, one alternative to fixing the problem (also see notes on word-break below), is to put in a non-zero value for the margin.
For a new diagram, EVE defaults to zero margins, pixels, and 100% scaling. Any changes you make to these settings will get saved along with the current EVE datafile. They are not saved to the "eve.ini" file.
You can see in the above graphic for "SVG configuration", that there are options for rendering quality.
The default I chose for text is "optimize legibility", as the default looks a bit fuzzy when text is small. The "automatic" option will give you the default. The choice "optimize legibility" is probably the closest in appearance to how the text looks inside EVE.
The default I chose for shapes is "crisp edges" as this gives edges to shapes that look like they render inside EVE. The "automatic" option puts a bit of fuzziness into the edges.
The above section, "take-1", describes the original method, and is the best place to start when learning about exporting EVE diagrams to SVG.
The "File" menu has two options for exporting to SVG:
This section describes the second option, "Export as SVG...". This was introduced with v3.07.
With this option, you don't highlight any elements beforehand, as the entire diagram is exported to SVG. Apart from this though, there is a fundamental difference from the first technique: this option uses the EVE window as the SVG "viewBox".
That is, it is WYSIWYG -- exactly as you see in the EVE window will appear in the web page. Therefore, to adjust what part of the diagram you see in the web page, you have to adjust the EVE window beforehand.
Don't forget though, that the entire diagram is exported, so even if you are viewing only a portion of it in the EVE window, and that's all you'll see in the SVG window, it is possible to scroll the SVG graphic, just as you do in EVE. Thus, this technique is excellent for very large diagrams, that you may have to scroll around in and maybe also zoom in and out.
With this option, you will find that the margins in the "SVG configuration" dialog box are greyed-out. The reason for this is that this is true WYSIWYG, meaning that what appears in the EVE window will be exactly what you see in the SVG window.
A quick experiment To get a quick idea of what this "viewBox" is all about, conduct this simple experiment:
Open the demo diagram that came with the eve.zip package: "eveintro.eve". Don't do anything, just go to "File/Export as SVG..." and save -- let's say it will be "test.svg". In Microsoft Windows Explorer, double-click on "test.svg" to open it in your web browser (or use File/Open... inside your web browser). There you are! Hold down ALT key and drag with mouse to scroll (Adobe viewer required).
Warning: With the current version of EVE, there is one disadvantage of the "take-2" method. With the "take-1" method, you first drag a selection rectangle around the elements of interest, and any continuously moving (animated) elements will come to rest at their "home" positions. This ensures that they will animate in the SVG graphic in the correct place. However, the "take-2" method takes a snapshot of the entire diagram as-is, and continuously moving elements may be displaced in the SVG graphic. I intend to fix this in a future version of EVE.
This section introduces plain text labels. HTML labels are introduced in the next section. Plain text labels have one font and size, etc., applied to the entire label.
One limitation of SVG is that the specification does not natively support word-wrap. So, EVE has to calculate the number of characters in each line of a multiline text label and compose them as separate lines in SVG code -- however they are grouped as a single element in SVG.
I have tried to do this word-break calculation accurately, but in some cases the break may occur in the SVG diagram slightly differently than in the EVE diagram (NOTE: this problem does not apply to HTML labels). I think that I've got this one fixed up, but just in case you encounter the problem, it is easily fixed by manipulating the bounding rectangle of the label, on the EVE diagram.
That is, left-click on a label handle, and a drag handle will appear on the side boundary. Drag it a bit further out or in.
There is however, an easy way to make sure a particular word starts on a new line -- put in a hard return, that is, the ENTER key.
The size, font, right-align, rotation, color, all export to SVG.
With version 1.89 of EVE, I put in a little bit of code that compares word-breaks between the EVE display and in the SVG file. This picture illustrates:
This shows the right-side resize-handle on a label element. Drag it to adjust the width of text. The grey box should totally enclose the text -- if it doesn't, as in the example here, it means that EVE has calculated the text when exported to SVG will fit in just three lines. That is, there is disagreement about where the word-breaks are.
From EVE's point of view, the grey box is for your information only. If you are intending to export the label to SVG, EVE is telling you that she thinks there is a word-break disagreement between what is displaying on the EVE screen and what will be exported to SVG.
The solution to this is simple -- drag the resize-handle until the grey box encompasses all the text. In the above example, if you drag the handle out (to the right), until the last word just comes up to the third line, you'll be right.
Certain characters are used for formatting in XML/HTML/SVG code. If these characters are in a plain-text label, they need to be converted to special formats to avoid being treated as formatting instructions.
The
< > & "
characters are converted to < > & " respectively in the generated SVG file.
Hard spaces are also converted to however the Adobe SVG viewer ignores them and always puts one space only. However, do not assume that this will always be the case for future versions of EVE. It is possible to tell the SVG viewer not to ignore the hard spaces, and I may implement this.
A text label can be rotated to any angle, in one degree increments. However, with the current version of EVE, multiline plain text labels do not rotate correctly. A single-line label rotates fine. For a large multiline label that has to be rotated, make it into a HTML label. EVE does a lot more work in calculating the positioning of words and lines for HTML labels, and they will retain correct appearance when rotated. Note that this extra work also imposes an extra workload for rendering within the EVE diagram.
See the next section for a decription of rotation of HTML labels.
The section above, "Exporting plain text", pertains to plain text labels. EVE from v2.50 supports HTML labels, and export of HTML labels to SVG was introduced with v2.70.
Any text label in an EVE diagram can be switched between plain text and HTML text, and in the latter case HTML tags are allowed to modify font characteristics. The recognised tags are documented in the EVE User Manual.
The problem described above of adjusting the resize-bounding-rectangle so that it encompasses the bottom line, does not apply to HTML labels. Exporting an HTML label to SVG will always display in the SVG graphic with the correct number of lines and correct line-breaks as is displayed in the EVE diagram.
However, there are slight rendering differences between the Win32 GDI API and the SVG viewer. There are also differences between different SVG viewers. Examples given below are for the Adobe viewer, version 3.0, which is somewhat superior (more correct) than other viewers that I have tried.
HTML labels may be left-justified, right-justified, centered, or fully-justified. Left-justified is the easiest, and fully-justified the most difficult to implement (that is, for me to code). The example below is of a fully-justified paragraph. Here is a label in EVE:
Here is the actual HTML source code (viewed by right-click on the label handle):
<p align="justify"><i>This</i> is a <b>bold</b> word, and this is <big>bigger</big> and <small>smaller</small> and <font color="#0000FF">colored</font> word.</p>
<text font-family="Times New Roman" font-size="12" fill="#000000" x="258" y="196"><tspan font-style="italic" x="258" y="196" word-spacing=".83">This</tspan><tspan word-spacing=".83"> is a </tspan><tspan font-weight="bold" word-spacing=".83">bold</tspan><tspan word-spacing=".83"> word, and this</tspan><tspan x="258" y="211" word-spacing="6.25">is </tspan><tspan font-size="13" word-spacing="6.25">bigger</tspan><tspan word-spacing="6.25"> and </tspan><tspan font-size="10" word-spacing="6.25">smaller</tspan><tspan word-spacing="6.25"> and</tspan><tspan fill="#0000FF" x="258" y="226">colored</tspan><tspan> word.</tspan></text>
<tspan x="3916 4339 4712 4991 5364 5779 6058 6431 6845 7269 " y="8195">paragraph.</tspan>
<text font-family="Times New Roman" font-size="12" fill="#000000" x="293" y="240"><tspan font-style="italic" x="293" y="240">This </tspan><tspan> is a </tspan><tspan font-weight="bold">bold </tspan><tspan> word, and this </tspan><tspan x="313" y="255">is </tspan><tspan font-size="13">bigger </tspan><tspan> and </tspan><tspan font-size="10">smaller </tspan><tspan> and </tspan><tspan fill="#0000FF" x="364" y="270">colored </tspan><tspan> word. </tspan></text>
<tspan font-weight="bold">bold</tspan> <tspan>, and furthermore</tspan
HTML labels can also be rotated. Here is the label, left-justified, at 45 degrees, again viewed with the Adobe viewer: When a rotated HTML label is exported to SVG, EVE will calculate the bounding dimensions so that none of the text is chopped off.
If you download the latest version of EVE, you will probably find that rendering accuracy is better than these pictures, as I am always tweaking the code, but slow to update the snapshots (or maybe not, it depends when I manage to get back to playing with that particular piece of code!)
In an EVE diagram, an icon may optionally have a bitmap picture that replaces its default square shape. When exporting to SVG, EVE extracts these bitmaps from the EVE database and saves them as separate files, in the same folder as the exported .SVG file. They are given unique filenames.
A bitmap that before importation was GIF, JPG or BMP, will be GIF, JPG or BMP again after being exported. What about PNG? The Win32 API doesn't have support for rendering PNG, so cannot be imported into EVE, however I am considering options for supporting PNG in the future -- if you consider this to be a high priority, let me know.
Note: this is also a technique for exporting bitmaps out of the EVE bitmap/picture library.
Prior to version 2.80, EVE combined link activation inside the icon element, along with the ability of an icon to display a picture. From v2.80, EVE has separated the link activation to a separate element, the link activator, that can be attached to any element. Thus, any element in the diagram can become a link. Links are very easy to use, and work as they do in an EVE diagram.
Inside EVE, you have the choice of double-click to activate a link, or either double-click or single-click. The equivalence of single-click is selected in the "Control/EVE preferences..." dialog box. However, in the SVG diagram, as per Internet standard practice, a simple left-click will activate the link. Furthermore, the cursor automatically changes to a little hand when over the element to which the link activator is attached. The hand cursor does not automatically happen within EVE, and requires the attachment of an animation activator element with the "Hand cursor" and "Mouseover" or "mouseclick" checkboxes ticked in the properties box.
One option that we don't have in SVG is a link to open another Windows application. You will see that this is one of the options for the link activator inside EVE, however the protected environment in a web page does not allow this to happen.
In the above example SVG graphic, the WWW link displays as a small bitmap, a face with goggling eyes. In this case, a picture icon has an attached WWW link activator. Note, this was originally created with a version of EVE prior to v2.80, so used the combined link/picture icon -- the latest EVE retains backwards compatibility with earlier diagrams.
As in EVE, the goto link scrolls the entire diagram to a specified destination. Here is a snapshot of part of the link activator dialog box:
The specified destination coordinates 400,100 are in diagram units and the diagram will be scrolled so that they are in the centre of the window. The diagram is scrolled with a time duration of 1 second in this example.
This also works in SVG, and is particularly useful with the "take-2" export method for large diagrams. The Adobe SVG viewer does allow the mouse and arrow keys to scroll the diagram -- for example, hold down the ALT key and you will see a hand cursor appear and you can then drag the diagram with the mouse (press left button and drag).
However, the goto link means that you can have an element in the SVG diagram that you can click on and the entire diagram will scroll. This is achieved by modifying the viewBox, as for example:
<svg id="Xview20" width="782px" height="514px" viewBox="-194 -18 782 514" preserveAspectRatio="none" text-rendering="optimizeLegibility" shape-rendering="crispEdges" > heaps of diagram in here! <a><image xlink:href="view27.gif" x="508" y="440" width="30" height="30" pointer-events="all" > <animate xlink:href="#Xview20" attributeName="viewBox" begin="click" fill="freeze" dur="6" to="-194 462" /> <animateMotion dur="1" begin="click" path=" m 0,0 l 0,480 z " /> </image> </a> </svg>
This example is a picture icon that has both an animation activator and a goto link activator attached. The animation activator generates the "<animateMotion ... />", while the goto link activator generates the "<animate ... />". The animation activator is described in the next section, immediately below.
Thus, click on the picture icon and the icon will move, but the "animate" references the "viewBox" property of the outer "<svg ... >". The "to=" specifies new top/left coords for the viewBox.
For the current version of EVE, this works best for absolute destination coordinates. The goto link activator dialog box also recognises relative destination coordinates, for example "h=230 v=-64 t=1", which will scroll the EVE diagram to the left by 230 diagram units and down by 64 units, over a time duration of 1 second. When exported to SVG, this works correctly the first time the picture icon is clicked on, but I have composed absolute destination coordinates into the "<animate ... to=" ... " />". I have not yet figured out from studying the SVG specs how to make a true relative change to the viewBox (let me know if you figure this out!). Hopefully I will be able to do this in a future version.
This is described in the main EVE User Manual.
The animation that you see in the EVE diagram will be the same in the SVG graphic, however Adobe's SVG Viewer does a nicer job of making the movement smooth.
When you throw a selection rectangle around a moving element or group of elements, wait until they stop moving before selecting "File/Export selected elements as SVG..." (if they are moving, that is). This ensures that they will start animating at the correct coordinates in the SVG file.
If you attach an animation activator to a standalone element, the element will be animated. "Standalone" here means that it has no owner and no children.
If you attach an animation activator to the "boss" element of a composite-object, the entire object will animate.
I'm referring to this example as a "composite object", which in EVE terminology refers to elements that are attached-to a common root owner (boss) and also "locked". Locking a child element in the EVE environment simply freezes it in-place relative to its owner and makes it into a single entity. For export to SVG, being locked or not doesn't matter -- the factor that makes a element a child of another is being attached to the owner/parent.
The animator attached to the boss will cause the entire composite-object (ie, including all the children elements) to move. The animator attached to the rectangle will move only the rectangle. The total effect is:
In this example, the animator attached to the ellipse moves the entire object horizontally, while the other animator moves just the rectangle vertically. The file "anicomp1.eve" to demonstrate this, is bundled with the EVE WE zip package.
Here is the essential part of the SVG code generated by the above example:
<g id="ident001"><text font-family="Times New Roman" font-size="12" fill="#008000" x="254" y="254"> Animated composite </text> <rect x="253" y="205" width="48" height="24" rx="0" ry="0" fill="#FF00FF" stroke="#000000" stroke-width="1" > <animateMotion dur="4" repeatCount="indefinite" path=" m 0,0 l 0,12 z " /></rect> <ellipse cx="234" cy="222" rx="20" ry="20" fill="#8080FF" stroke="#000000" stroke-width="1" > <animateMotion xlink:href="#ident001" dur="4" repeatCount="indefinite" path=" m 0,0 l 50,0 z " /> </ellipse> </g>
You can see from this how EVE creates a group of all elements that are attached to the common "boss" element. In this example, the group is named "ident001".
You can see that one of the "animateMotion" tags has "xlink:href="ident001"". What this means is that if the appropriate trigger event occurs over the ellipse, the animation will apply to the entire group.
On the other hand, you can see that the "animateMotion" attached to the rectangle will only animate the rectangle if an appropriate trigger event occurs over the rectangle.
Warning 1: element ordering A minor warning here. When EVE is composing the SVG file, she searches through the database to find all elements belonging to the group, as per "ident001" above and composes them contiguously in the SVG file. However, they may not have been contiguous in the EVE database (though they most likely were), which leads to the possibility that other elements in the selection being exported to SVG may be composed into the SVG file out of order. This means that they will render in the SVG viewer out of order. The outcome of this is that an element in EVE that renders on top of another, may render in the SVG viewer underneath that other element (or vice versa). Of course, you will know when this occurs and can correct it. It is absolutely necessary for EVE to perform this reorganisation to compose the groups.
Warning 2: 2-deep nesting Animation can only nest 2-deep. The above example is an illustration of this. 2-deep means that an animation activator can be attached to the child of an animated group, but a third animation activator cannot be attached to a child-of-a-child in the group. Or rather, it can, and it will work inside EVE, but will not behave as expected when exported to SVG. The reason for this is that the EVE export code can only nest animations 2-deep.
The above example shows continuous motion. However the animation activator properties box allows various events to trigger the animation. Currently, the modes are continuous, off, mouse-over, mouse-on, and mouse-click.
This little picture shows three ellipses: The rightmost is attached to (owned by) the middle, and the middle is owned by the leftmost ellipse, making the leftmost element the "boss". The animation activator is attached to the boss, and when animation occurs, all three ellipses will animate. However, inside EVE, a mouse event is only triggered when over the boss element. Ditto for the link activator.
When this piece of diagram is exported to SVG, this is the generated code:
<g id="group001"><a><ellipse cx="254" cy="157" rx="20" ry="20" pointer-events="all" fill="none" stroke="#000000" stroke-width="1" > <animateMotion xlink:href="#group001" dur="5" begin="mouseover" path=" m 0,0 l 0,20 z " /> </ellipse> </a><ellipse cx="293" cy="150" rx="20" ry="20" pointer-events="none" fill="none" stroke="#000000" stroke-width="1" /><ellipse cx="332" cy="152" rx="20" ry="20" pointer-events="none" fill="none" stroke="#000000" stroke-width="1" /></g>
The topmost ellipse is the boss. The dummy "<a> ... </a>" tags around it cause the SVG viewer to display a pointing hand cursor. The "pointer-events="all"" causes this element to be sensitive to any mouse activity anywhere over it. The other two ellipses are not responsive to any mouse action. The cursor does not display the pointing hand, nor does any mouseover or mouseclick cause any action. This code is consistent with behaviour inside EVE.
Note that if I had also attached an animation activator to the rightmost ellipse, then it would have composed with "pointer-events="all"" (remember, 2-deep nesting is allowed).
Note that an element may also compose with "pointer-events="stroke"" if the element is set as "selectable only on boundary" (substitute "vertices" for polygon/line) in EVE.
The animation activator properties box also has settings for changing color and visibility during animation.
<g id="ident001"> <ellipse cx="214" cy="166" rx="20" ry="20" pointer-events="all" fill="#F8D52E" stroke="#000000" stroke-width="1" > <animateMotion id="ident002" xlink:href="#ident001" dur="2" begin="click" path=" m 0,0 l 50,0 z " /> <animate attributeName="filter" to="url(#negativefilter)" begin="click" end="ident002.end" repeatCount="indefinite" dur="0.5" /> </ellipse> </g>
Mouse-click This case is shown in the above code. The "animateMotion" tag provides the coordinate movement, while the "animate" tag flashes the color. In the case of the latter, a color filter is applied to the ellipse, at 0.5 second intervals, beginning when there is a mouse click and ending when the "animateMotion" ends. Color flashing will still work if horizontal and vertical movement are both zero. Even if time is zero, EVE will compose a minimum time of one second.
Mouse-over If the start event is mouse-over, there is a difference for the end condition. For mouse-over, the animation continues to play as long as the mouse is over the target element. "animateMotion" will loop, playing until a mouse-out occurs, which means that color-flashing will also occur. The generated code is:
<animateMotion id="ident002" xlink:href="#ident001" dur="1" begin="mouseover" end="mouseout" path=" m 0,0 l 0,0 z " /> <animate attributeName="filter" to="url(#negativefilter)" begin="mouseover end="ident002.end" repeatCount="indefinite" dur="0.5" />
Mouse-on If the start event is mouse-on, it works just like mouse-click, looping once then stopping. A mouse-out must occur to re-prime the trigger detection, and another mouse-on will cause another animation loop.
<g id="ident001"> <a><ellipse cx="214" cy="166" rx="20" ry="20" pointer-events="all" fill="#F8D52E" stroke="#000000" stroke-width="1" > <animateMotion id="idani013" xlink:href="#ident001" dur="2" begin="click" path=" m 0,0 l 50,0 z " /> <set attributeName="filter" to="url(#negativefilter)" begin="click" end="idani013.end" /> </ellipse> </a> </g>
The "set" tag applies the negative filter to the target element on a mouse-click and it remains inverted until "animateMotion" completes its loop.
<animateMotion xlink:href="#ident001" dur="2" begin="click" path=" m 0,0 l 50,0 z " /> <animate attributeName="filter" to="url(#negativefilter)" begin="click" dur="0.5" />
You can see that the "animate" color inversion runs for 0.5 seconds, regardless of the duration of "animateMotion".
Although mouse-over causes the animation to repeat until a mouse-off, the color will still only flash once on the initial mouse-over.
The above section describes the color animation of the element to which the animation activator is directly attached. It was also explained earlier that for coordinate animation all children also move, however in the case of color, a child only color-animates if it's "Lock" checkbox is ticked.
This code gives an example:
<g id="ident001"> <ellipse cx="244" cy="159" rx="20" ry="20" pointer-events="all" fill="#F8D52E" stroke="#000000" stroke-width="1" > <animateMotion id="idani015" xlink:href="#ident001" dur="2" begin="mouseover" path=" m 0,0 l 40,0 z " /> <animate attributeName="filter" to="url(#negativefilter)" begin="mouseover" end="idani015.end" repeatCount="indefinite" dur="0.5" /> </ellipse> <rect x="218" y="104" width="48" height="24" rx="0" ry="0" fill="#5FEC53" stroke="#000000" stroke-width="1" pointer-events="none" > <animate attributeName="filter" to="url(#negativefilter)" begin="idani015.begin" end="idani015.end" repeatCount="indefinite" dur="0.5" /> </rect> </g>
What we have here is an ellipse with attached animation activator. The ellipse also has a child rectangle, locked. The fact that the child is locked causes EVE to generate the second "animate" tag, that applies to the rectangle. Note that it's "begin" and "end" is tied to the "animateMotion" tag of the animation activator.
In a nutshell, the color animation of the locked child (the rectangle) tracks the color animation of the animated element (the ellipse).
This works exactly as described in the standard EVE User Manual. This illustrates:
The intention of this mechanism is to easily create 3D buttons and borders. Although on the extreme right side of the above graphic is shown an example of a gradient over a long distance, it is not recommended that this be done for export to SVG.
EVE draws the color gradients as color bands, and this is very inefficient for long gradients as on the extreme right. It works well for border effects as shown in the other examples.
An example of a 3D button with side-light can be seen at http://www.goosee.com/library/freelayoutwebpage/ (the SVG result) and freelayoutwebpage.eve.
This is a very exciting new feature of EVE. In a nutshell, you can see the generated SVG code in quasi-realtime while working on the diagram, and you can customise the code. This serves two main purposes:
Let's demonstrate with a simple example:
You are allowed to leave this window open while you continue to work on the diagram. Simply press the "RELOAD" button whenever you want to update the generated SVG code.
The inline activator can be attached to any element on the diagram, and you can immediately view the SVG code pertaining to that element. This is a great learning tool.
However, the inline activator is a far more powerful tool than simply displaying SVG. It also enables you to customise any aspect of the generated SVG code. This customisation will appear in the final SVG file, that you produce via "File/Export selected elements as SVG..." and "File/Export as SVG...".
There are two text boxes in the dialog box shown above. The top one is read-only, and displays the SVG code that EVE generates. The bottom edit box is for you to enter custom code. You are able to modify the attributes of the element to which the inline activator is attached. For example, say that you would like to take advantage of the "opacity" feature of SVG, that EVE curently does not support. No problem, you can type it in:
Type in your new custom attributes (or properties), press the "RELOAD" button, and the custom attribute will appear in the top edit-box, as shown by the yellow line.
Now for a most important point: the custom attribute is inserted into the <ellipse ... > properties, as that is what the inline activator is attached to. Reiterating this point:
Custom attributes apply to the element to which the inline activator is attached.
Ok, say that what you want to do is customise the animation. Simple -- attach an inline activator to the animation activator. You see, it's very logical -- attach an inline activator to whatever element whose properties you want to customise.
Here is a piece of EVE diagram with inline activator attached to the animation activator -- in fact, there are two of them attached:
One thing that I must emphasis about all of this -- it is very easy to do. You can't go wrong, because when you right-click on an inline activator, you will see the actual SVG code that EVE will generate. Thus, you can experiment to your hearts content, before finally generating an SVG file.
You can see from the above snapshots that there is a "Replace all attributes" option. This does what the name says. In the following example, I typed some text into the bottom edit box, then pressed "RELOAD":
You can see in the above snapshot that all the default properties inside "<ellipse ... >" have been completely replaced by my custom text. Note, that EVE performs this substitution as-is, without making any changes to the custom text.
The fact that the substitution is made as-is, is very significant, as a skilled SVG coder may insert any code, including tags or scripts.
The great beauty of the inline activator, apart from its simplicity and elegance, is that you can now apply anything that is in the SVG specification. A major problem with the SVG standard is that it is so feature rich, and none of the editors or viewers that I know of are able to implement all of it. EVE is in the same predicament, but now there is a simple mechanism to incorporate any SVG feature not yet supported by EVE.
I welcome suggestions on how to take this inline SVG feature in the future. One thing I am thinking is to allow insertion of attributes for the <tspan> ... </tspan> multiple lines of text labels, by attaching multple inline SVG activators, one for each line. Another thing that has occurred to me is that I could incorporate some basic parsing of the custom code such that instead of just appending the attributes at the end or totally replacing, a custom attribute could override an existing one.
When EVE starts up, she reads a customisation file called "eve.ini", that is located in the same folder as the executable "eve.exe". If "eve.ini" does not exist, it is created.
When you generate an SVG file, EVE uses a default header section. That is, the first 4 or 5 lines of the file. If for any reason you don't like this default, you can change it. All that you need to do is use a text editor to enter the following lines into "eve.ini":
[svgpre]line1=<?xml version="1.0" encoding="iso-8859-1"?>line2=<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"line3="http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">line4=<!-- Generated by EVE, www.goosee.com -->line5=
If there is already some text in the file, leave it alone, and make sure that you leave a blank line above "[svgpre]". For example, the complete "eve.ini" file could look like this:
[open]file1=C:\2002\eve_dev\eveintro.eve [preferences]feveprefs=32fviewprefs=0xfineprn=0yfineprn=0nbackground=0charsetdefault=0szeditor=WRITE [svgpre]line1=<?xml version="1.0" encoding="iso-8859-1"?>line2=<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"line3="http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">line4=<!-- Generated by EVE, www.myeve.org -->line5=
"line1=" specifies what will go on the very first line of the generated SVG file, and so on. You can have up to five lines, and if you leave any line empty, such as shown for "line5", nothing will be generated for that line. In this example, the header is just four lines. If you leave off a line, say the "line2=<!DOCT.... " line, EVE will use the default for that line.
Note, there is a limitation of 127 characters maximum on each line. If you go over this, it will be truncated.
The menu "File/Import SVG..." allows you to import an SVG file into EVE.
When imported, the imported elements will automatically follow the mouse pointer, so you can deposit them wherever you want by clicking the left button.
This feature was introduced with EVE version 2.16 and is to be treated as "pre-alpha" at this stage. The "evewe.zip" package contains the file "imp2.svg" that you can test -- this imports perfectly. However, other SVG files may not import correctly.
It is intended that the capabilities of the import filter will be gradually extended.
The Adobe SVG Viewer officially supports Internet Explorer and Netscape, on Windows, Mac, Linux and Solaris. However, you will need to hunt around on the www.adobe.com website to find the download file for the Linux and Solaris versions -- it's currently a beta release. UPDATE, OCT 2002: There is a problem with Mozilla versions after 0.9.8 and Netscape after 6.2 -- the Adobe SVG viewer v3.0 doesn't work. Native support for SVG is under development, however it is not mature. I presume that Adobe will bring out a fix soon. (Personally, I'm using Crazy Browser, that uses the IE HTML-rendering DLLs, to view pages with SVG). UPDATE, AUG 2003: To view SVG with Netscape 7, Mozilla 1.x and Firebird, you need the Adobe SVG viewer version 6.0 beta. This can be downloaded from: http://www.adobe.com/svg/viewer/install/beta.html --currently only for Windows 95/98/me/NT/2000/XP.
On my Win 98 PC, I had Internet Explorer 5.5 as the default browser. When Adobe SVG Viewer installed, it ignored Netscape. Consequently, I could not see SVG graphics inside Netscape, but could in IE.
This was fixed by manually copying these files:
npsvg3.dll npsvg3.zip
from folder c:\program files\common files\adobe\svg viewer\ to folder c:\program files\netscape\netscape 6\plugins\
Incidentally, I also discovered that the Adobe SVG Viewer installed some files at c:\windows\system\adobe\svg viewer 3.0\, including an interesting readme html file.
SVG images generated by EVE all work ok in Netscape 6.2.
Netscape will soon have native (inbuilt) SVG support, being beveloped as part of the Mozilla project, so won't require a third-party plugin.
Note that Netscape v7.0 beta has a problem with the Adobe SVG Viewer (like, it crashes). Ditto for Mozilla v.1.0 RC3.
You need Adobe SVG viewer v6 beta. For manual install, copy these files to the browser plugins folder:
npsvg6.dll npsvg6.zip
--you'll find them in c:\program files\common files\adobe\svg viewer 6.0\plugins (after the SVG viewer has been installed).
The following is an extract from http://www.siliconpublishing.org/svgfaq/Opera.asp (also see http://www.adobe.com/svg/indepth/faq.html#installother):
Why doesn't the Adobe SVG Viewer install in Opera with the basic install? According to Michael Bierman from the Adobe SVG FAQ: Adobe is not committed to supporting the Opera browser at this time. Instead, we are focusing our initial efforts on the most widespread platforms. Our installer does not recognize Opera, Amaya, or other browsers, but you may be able to copy the SVG plug-ins from your Netscape plug-ins folder to the plug-ins folder of a different browser. The relevant files are: NPSVGVw.dll, SVGView.dll, and SVGViewer.zip. Can I still use the Adobe SVG Viewer with Opera? Yes, Andrew Watt has confirmed that the viewer will work with Opera by copying the relevant files to the plugins directory as suggested by Michael Bierman above, but there are some inconsistencies with performance in other browsers. Andrew Watt writes: The visible display seems fine, essentially the same as in IE5.5. The only significant problem in Opera which I have spotted so far is that XLinks within SVG e.g. on www.svgspider.com/default.svg don't seem to work at all.
Why doesn't the Adobe SVG Viewer install in Opera with the basic install?
According to Michael Bierman from the Adobe SVG FAQ: Adobe is not committed to supporting the Opera browser at this time. Instead, we are focusing our initial efforts on the most widespread platforms. Our installer does not recognize Opera, Amaya, or other browsers, but you may be able to copy the SVG plug-ins from your Netscape plug-ins folder to the plug-ins folder of a different browser. The relevant files are: NPSVGVw.dll, SVGView.dll, and SVGViewer.zip.
Can I still use the Adobe SVG Viewer with Opera?
Yes, Andrew Watt has confirmed that the viewer will work with Opera by copying the relevant files to the plugins directory as suggested by Michael Bierman above, but there are some inconsistencies with performance in other browsers. Andrew Watt writes: The visible display seems fine, essentially the same as in IE5.5. The only significant problem in Opera which I have spotted so far is that XLinks within SVG e.g. on www.svgspider.com/default.svg don't seem to work at all.
My additional note to this, is see the comment for Netscape above, and get those same files.
See: http://www.konqueror.org/. Konqueror is the browser supplied with KDE, running on Linux.
Konqueror supports Netscape plugins, so I presume will run the Adobe SVG Viewer.
Konqueror has its own native SVG support, "ksvg". I don't know how good this is. And, I presume that "ksvg" is intended for viewing SVG graphics in all KDE apps. Great. I just checked the kde.org website, and KOffice 1.2 will have inbuilt SVG support -- yippee!
K-Meleon v.0.6 is now the default browser on my own PC. I have provided a rationale for this on my "Best of the best" freeware page.
K-Meleon accepts Netscape plugins. If you have already installed the SVG Viewer for another default browser, copy those two files, npsvg3.dll npsvg3.zip, as explained above for Netscape 6, into:
c:\Program Files\K-Meleon\plugins
Then startup K-Meleon and SVG graphics are displayed beautifully. I have not found any incompatibilities with SVG graphics generated by EVE.
K-Meleon will soon have native (inbuilt) support for SVG, being developed as part of the Mozilla project.
Amaya is both a WYSIWYG HTML editor and a browser.
Has some bugs. Version 6.1 ignores the "type=" entry in "embed" tags, so the HTTP server at your website must be configured to serve SVG graphics with the correct mime type.
Amaya has in-built SVG support, which is fairly advanced. Lots of things it doesn't understand in SVG files generated by EVE -- nice though, Amaya generates a parsing error report, so you can see what lines it objected to in the source code. Amaya will do this faor any web file.
Amaya doesn't understand SVG hyperlinks and animation.
I like Amaya, in particular because it's an open-source project and is multi-platform. I don't recommend it as a browser, as there's too much missing for general browsing. As an editor though, it's nice.
I have put some stuff in here on pros and cons of various WYSIWYG HTML editors, mainly with regard to support of SVG. These are just some of my impressions, not exhaustive tests. Also, many of the editors that I am comparing are not the latest versions, so keep that in mind.
CONS
PROS
The free Frontpage Express is basically the same, but less features.
FrontPage has a site manager, but it generates an incredible number of management files -- quite disgusting amount of extra weight -- other site managers such as Namo don't do this. Also, Namo doesn't install a "personal server" on your PC.
COMMENT: It used to be available free at www.aolpress.com, but it's not there anymore -- is it on the AOL CD?
I don't understand why they couldn't put color-coding into the HTML source code, when they did it in Navigator (the browser).
I edited one of my files, made some changes in a table. It messed up the table, then when I opened the file later in Namo, found that all the tables had been messed up, with tags that Namo couldn't understand, and which resulted in incorrect rendering of the tables. I did notice afterward that a checkbox labelled "Automatically reformat HTML source" in Composer preferences was ticked by default -- maybe that's the culprit.
I got this off the front of a magazine. Sophisticated product, with site management.
I decided to uninstall it from my PC. Reason is, it launches "osserver.exe" when Windows starts up, and there is no option for disabling it. I really don't want another background process, especially one with the name "server" in it while I'm on the Internet. I used System Mechanic to disable "osserver" at startup, and HyperText Studio seems to still work -- maybe this is like MS FrontPage, that will work without its personal server. Namo WebEditor doesn't need a server, and Namo is my favourite anyway.
Has in-built support for displaying SVG graphics. You can even create SVG graphics, but primitive. Open-source project, multi-platform. WYSIWYG editor, with source code window, can edit in either and synchronise between them.
Very standards-compliant, and shows parsing errors when open existing HTML files. But, will still render non-standard code.
Some features are primitive, such as table editing.
Find out more in my "Best of the best" page.
http://www.goosee.com/ (c) Copyright Barry Kauler 2002, 2003.
