Date of last update: 2008-03-05
SVG, test-suites and Opera
Operas fixed bugs history of SVG
(if you miss an identifier on this page, it is maybe moved to this page)
Up to now, unfortunately the test-suites of W3C for SVG are not very detailed. A lot of SVG-features can not be tested with them, but nevertheless, they are part of the specification. So we need to help developers with simple examples, what is not working yet, but should, according to the specification. I tried to reduce errors to minimal and essential examples, maybe helpful to test other user-agents too.
(Ich bin)
Ein Teil von jener Kraft,
Die stets das Böse will und stets das Gute schafft. ...
Ich bin der Geist, der stets verneint!
Mephistopheles, Johann Wolfgang Goethe (Faust I, Studierzimmer, 1335ff)
Opera 8.x was published with the ability to support the tiny profile of SVG 1.1 and Opera claims, that
Opera9 supports the profile basic of SVG 1.1 since the version beta 1 (published 2006-04-11, build 236).
Of course, this is not completely true, there are several errors and gaps for both profiles. And
even in Opera 9 there are errors and gaps in the support of the tiny profile. There is
still a lot of work and many errors and gaps to find and to be fixed - lets get them!
Opera published lists of supported parts of SVG for
Opera9 (This is build 344 from 2006-06-16, just for comparsion).
These lists contain some further gaps, not mentioned here. Some points in these lists
are not consistent with errors and gaps noted here, mainly because these lists are less detailed as a
systematic test of these features. Maybe we can take it as lists, Opera believes, these features should
work (or it is already known, that they do not work yet). Deviations between real behaviour and these
lists seem to be worth to report to Opera, either to correct the lists or the behaviour.
For animation I offer a special test area with a systematic test ensemble for animation of SVG. Tests will be continued until I give up or it will work ;o)
For users and authors:
Do not blame anybody, if you have not even read the specifications.
And you have to read the specification carefully and you have to distinguish
between different profiles and versions.
Note, that SVG-tiny or SVG-basic cover just a large part of SVG, but not everything,
so it is not an error, if features of SVG are not supported, that are not included in SVG-tiny
or SVG-basic.
You have to read SVG-mobile specification to optimize your files. Normally, SVG-mobile just
refers to the SVG-specification. You have to look carefully at the restrictions.
Opera 8 is already able to support a few parts of SVG basic like opacity and parts of gradients,
the Opera 9 Technology Preview 1/2 support already more parts of of SVG basic like tspan,
parts of text on a path, filters, for them the author has to try examples, what already
works and what is incomplete and contains errors. Opera 9 beta 1 is expected to support the
basic profile completely. For Opera 9.50 alpha is noted, that it supports parts of SVG tiny 1.2 too.
Often it is easy to reduce SVG-documents to SVG-tiny. For example instead
of CSS you have to use almost the same presentation-attributes of SVG and you can collect
elements with the same values of attributes in groups to define something like
CSS-classes. Instead of animation with (ecma-) scripts declarative animation can be used,
not just with SVG-tiny, but with deactivated scripting and full SVG-support, too.
So in many cases the accessibility with more user-agents gets better with a
reduction to SVG-tiny.
All examples were tested on Debian-Linux (stable) with the static versions, most of them tar.gz
Severity: accessibility problem and specification violation SVG tiny 1.1.
Description: xlink:role and xlink:arcrole references not accessible
xlink:role and xlink:arcrole for elements like a, image, use etc provide a possibility to give a description
of the referenced document respectively the referencing arc in an external document. Obviously this
becomes only useable both for authors and users, if the noted URIs are accessible somehow.
This could be done for example on demand in the content menu similar to zooming or pausing of
animation. In an alternative text representation of the document
this should be noted too.
SVG and XLink do not note details, how this has to be realise, but SVG references XLink as normative
description for them and it is obvious, that they have a well defined functionality related to accessibility
similar to the SVG elements title and desc and should be accessble too
somehow.
Example:
image, xlink:role and xlink:arcrole
Note, that the URIs of xlink:role, xlink:arcrole, xlink:href are not even available in the info panel of Opera.
Comment: Other viewers have a similar accessibility problem for these elements. bug-316543.
Severity: specification violation SVG tiny 1.1.
Description: keyTimes ignored for animateMotion
Example 1:
animateMotion and keyTimes
Some circles are moved along a square with
a duration of 30s.
All have the same timing, therefore the top
blue circles cover the other red ones.
The blue ones use a simple path referenced by
mpath or the same path using the path attribute
or values, all with keyTimes and calcMode linear.
The red circles below use values and either
keyTimes with animateTransform or a group separated
animateMotion resulting in the same timing for comparison.
If something red circles gets visible, an error is occured.
Comment: Ok in the adobe plugin and in Squiggle 1.7, wrong in Opera.
Example 2:
animateMotion and keyTimes
Some circles are moved along a path with
a duration of 30s.
All have the same timing, therefore the top
blue circles cover the other red ones.
The blue ones use a simple path referenced by
mpath or the same path using the path attribute,
all with keyTimes and calcMode linear.
The red circles below use path and a group separated
animateMotion resulting in the same timing for comparison.
If something red circles gets visible, an error is occured.
Comment: Ok in the adobe plugin and wrong in Squiggle 1.7 (only problems with multiple M/m commands here) and Opera.
Example 3:
animateMotion and keyTimes
Some circles jump a few times along a path with
a duration of 30s.
All have the same timing, therefore the top
blue circles cover the other red ones.
The blue ones use a simple path referenced by
mpath or the same path using the path attribute
or a simple path given with values,
all with keyTimes and calcMode discrete.
The red circles below use path and a group separated
animateMotion resulting in the same timing for comparison.
If something red circles gets visible, an error is occured.
Note, that control points and M/m commands except the
initial from the path do not contribute as jump points, therefore
there are exactly 5 jump points for each path.
Comment: Wrong in the adobe plugin, Squiggle 1.7 and in Opera. bug-316541.
Severity: specification violation SVG tiny 1.1.
Description: animateMotion confused by path fragments of length zero
Example:
linear animateMotion and zero path length
A path with several path fragments of zero length is used for a
linear animateMotion of a blue square. The path is given in gray,
some simpler animateMotion elements are used to perform the same
motion for a red square exactly below the blue one.
If something red gets visible, an error is occured.
Comment: There are more problems the calcMode discrete or paced. This example is correct in the adobe plugin (but has other problems than Opera for the other values of calcMode). bug-285856 (not send by me).
Severity: specification violation SVG tiny 1.1.
Description: conditional processing ignored for animation elements
Example:
switch and animation
A switch is used with systemLanguage on a set element.
The set switches the color of a gray square to blue at 2s,
not to red as the alternative set would do, if the systemLanguage
is not supported. Red indicates an error.
The systemLanguage is derived from the related
parameter HTTP_ACCEPT_LANGUAGE from the viewer.
An additional string of a supported systemLanguage
can be given manually with the GET parameter 'lang'.
Opera ignores the switch and performs the second animation too.
More examples for SVG 1.1: conditional processing and animation 1.1
More examples for SVG tiny 1.2: conditional processing and animation 1.2
bug-303312.
Severity: crashes Opera 9.50 alpha/beta (and error in the interpretation of discard).
Description: Opera 9.50 alpha/beta crash with the given interactive discard example
Example:
interactive discard example
After several (two or more) clicks on different dark blue circles in the bottom line Opera 9.50 alpha
crashes. Note, that there is an error with the discard of the right circles too, they are not always removed.
Description of the test sample:
Using the an event to discard the circle respectively the g element around the circle
and using the begin of the discard as a syncbase-value to set the display of the small
circle to none at the same time.
Test is ok if the circles above are discarded and not displayed,
if the bottom circles are clicked or activated,
the left and the right ones directly, the middle ones 2s retarded. bug-303309.
sample to show the same visual effect using set without error or crash
Severity: specification violation SVG tiny 1.2.
Description: Opera 9.50 alpha/beta does not fill the viewport of an animation element completely with viewport-fill (-opacity)
Example:
viewport-fill and animation element
The viewport-fill for an animation is animated in the
blue range within 20s. If the viewport is not
completely and always somehow blue
an error is occured. If it is red, the
animation is not applied.
On bottom right there is a small rectangle having the same
fill animation as the viewport for comparison.
Opera only fills behind the referenced document, not the viewport parts on the left and right of the
referenced document. They appear due to the combination of widths and heights and preserveAspectRatio.
Example:
viewport-fill-opacity and animation element
The viewport-fill-opacity for an animation
is animated in the
blue range within 20s.
On bottom right there is a small rectangle having the same
fill animation as the viewport for comparison.
Opera does not animate the opacity left and right from the referenced document.
bug-295472
Severity: specification violation SVG tiny 1.2.
Description: Opera 9.50 beta does not switch back to the underlying value of editable if its animation is ended.
Example:
editable sample
After a click on the small blue circle the textArea
with a silly poem can be edited for 10s, indicated by a
blue stroke of the rectangle.
With the small magenta circle editing can be stopped
alternatively.
In Opera 9.50 beta editable does not switch back to none automatically after 10s. bug-295471
Severity: specification violation SVG tiny 1.1. Regression compared with Opera 8 and 9 < 9.50.
Description: animation corrupted if attributeType XML is overwritten with a higher priority attribute auto animation
Example:
attributeType and priorities
If an attributeType XML is overwritten with a higher priority attribute auto animations beginning
at 2s, Opera9.50 alpha/beta ignores the higher priority animations. In this fill animations the fill
is switched to black instead of performing the higher priority animation in the blue range.
Comment: Ok in the adobe plugin and in previous versions of Opera 8 and 9. bug-295469
fixed in 9.50 beta (build 1737)
Severity: specification violation SVG tiny 1.1. Regression compared to Opera 9.00 beta 1 (!)
Description: Opera uses the wrong correction for ry for a rectangle with rounded corners, if only rx is given and is too large.
Example:
rectangle with rounded corners
A blue rectangle with rounded corners has to be rendered.
According to
SVG1.1 rect element
the following has to be done to determine the correct(ed) values
for rx and ry:
'If a properly specified value is provided for rx but not for ry, then the user agent processes the 'rect' element with the effective value for ry as equal to rx. If a properly specified value is provided for ry but not for rx, then the user agent processes the 'rect' element with the effective value for rx as equal to ry. If neither rx nor ry has a properly specified value, then the user agent processes the 'rect' element as if no rounding had been specified, resulting in square corners. If rx is greater than half of the width of the rectangle, then the user agent processes the 'rect' element with the effective value for rx as half of the width of the rectangle. If ry is greater than half of the height of the rectangle, then the user agent processes the 'rect' element with the effective value for ry as half of the height of the rectangle.'
In this case the final results are rx="100" and ry="50".
Opera uses ry="100" too, this is just the first half of the correction - the
result is not the expected ellipse indicated in thin light gray or the
related rectangle given in red.
Comment: Ok in the adobe plugin, in KSVG1, inkscape... Wrong since Opera9 beta 2, ok in Opera 9 beta 1. bug-294478.
Severity: specification violation SVG 1.1 (respectively tiny 1.2 for requiredFormats).
Description: Opera claims to support scripting, even if scripting is switched off by the user
Example:
testing script and requiredFeatures
The display of this document depends on a switch of
the feature string for script and on ecma-script.
First case: feature string returns true for script
and scripting is active - the user gets a request
to switch off scripting to continue with the test
(with a reload).
Second case: feature string returns true for script
and scripting is not active - the user gets an
information about an error. The document
contains only ecma-script. If the viewer is not
able to interprete this, it should have returned
fail for the feature string for this document.
Third case: feature string returns fail for script
and scripting is active anyway - the user will
see an animation and an information about
an error - scripting should be not available, if
the feature string returns fail in general.
Fouth case: feature string returns fail for script
and scripting is not active - the user will see
a comment to switch on scripting to continue
with the test (with a reload).
Note that the featureString gives an information, wether
the feature is supported for this document or not, not if it is in
general possible that the feature can be supported under some
specific condiditions, in this case only if scripting is enabled.
If feature strings have any benefit for authors, the return value
of the feature string has to depend on the specific current
conditions for the related document and user preferences,
not on a general philosophical statement of the viewer.
The scripting used in this document is similar to set animations
of the display property to none, respectively to block to display
the additional information to the user related to scripting.
similar tiny1.2 test including requiredFormats
Opera claims always to support scripting, even if it is switched off by the user. This is an accessibility problem. With this behaviour it is very difficult for authors to switch between content without scripting and alternative content using scripting for whatever purpose. Note, that using requiredFormats in SVG tiny 1.2 instead of requiredFeatures would be even more effective, but does not work with Opera either.
bug-293838
Severity: specification violation SVG tiny 1.1.
Description: rendering error: residual mysterious line in Opera 9.50 alpha
Example:
path with rendering error
On top there is a small horizontal line, this is the rendering error.
Because stroke-width is the smallest structure, there cannot be a smaller
structure as the stroke in the image. The horizontal line is clearly smaller as
the stroke-width. The error depends strongly on the height of the svg, the
viewBox and the choosen path, the presence of the
z command, the stroke-linejoin.
Comment: bug-290933.
Severity: specification violation SVG tiny 1.1.
Description: by animateMotion not additive
Example:
by animateMotion
Test whether a by animateMotion is additive or not.
Red indicates an error.
Comment: bug-285857, not send by me.
fixed in 9.50 alpha (build 1629)
Severity: specification violation SVG tiny 1.1 for Opera 9.50 alpha; regression compared with Opera 9.0x, 9.1x, 9.2x.
Description: animateTransform of type skewX/Y not cumulative
Example:
cumulative animateTransform skewX/Y
Test whether animateTransform of the type skewX/Y is
cumulative or not.
Red indicates an error.
Comment: bug-285858, not send by me.
Severity: specification violation SVG tiny 1.1.
Description: too bad interpolation for calcMode spline, keySplines
Example:
animate with calcMode keySplines
The cy of a blue stroked circle is animated with six different values
animations using calcMode spline and keySplines.
The cx is animated linear with values animations to get
two dimensional trajectories.
The resulting trajectories are displayed within the active duration
as gray paths. These paths cover always completely the red fill
of the circle.
If the red center of the circle gets visible, an error is
occured.
The timing of the cx animations is choosen in such
a way, that the keySplines correspond directly to a cubic
path as trajectory. The keySplines values have to be multiplied
only with the related values, to get the path data.
The required accuracy of positioning has to be within one device pixel.
Opera does not meet this required accuracy indicated in situations with
large acceleration when the red center of the circle gets visible.
Comment: bug-287959
Severity: specification violation SVG tiny 1.1 for Opera9.50 alpha; regression compared with Opera 9.0x, 9.1x, 9.2x.
Description: too bad path interpretation with animateMotion and timing
Examples:
quadratic path interpretation and timing
cubic path interpretation and timing
Testing accuracy of path interpretation using stroke-dasharray, stroke-dashoffset and
animateMotion.
A symmetrical quadratic path stroked in dark blue is used for the test.
Magenta is the painted curve fraction of 0.5 of the complete path.
The end point of the painted fraction is painted yellow - this is the
test point at the half path.
Centered black concentrical circles test the accuracy of animateMotion
stopped with different methods at the test point at the half path (after 1s of animation).
A dark blue scale with yellow markers is aligned in such a way, that
the yellow markers are between the different circles, respectively mark
the positions of the stroke-dasharray fractional path.
Click the dark blue path to see the complete path, click the magenta
path to see details around the test point.
The required accuracy of positioning has to be within one device pixel.
Opera 9.50 alpha does not meet this required accuracy anymore. Previous versions
did.
Comment: bug-287958
Severity: specification violation SVG 1.1 for Opera9.50 alpha; regression compared with Opera 9.0x, 9.1x, 9.2x
Description: view element ignored
Example:
element with static and animated view targets
Four views are given as targets of an animated xlink:href attribute
of an a element. Colors are changed and the outline of the view displayed
just to give a timing. Another static view is given with the dark blue
small centered circle.
Click on the circles to see the target view.
Comment: bug-286643
Severity: specification violation SVG tiny 1.2
Description: stroke with vector-effect non-scaling-stroke disappears if scaled to zero
Example:
scale a rectangle to a height of zero without changing the stroke-width
The size of a blue path is scaled down in 5s
with several values for x and y to zero.
The vector-effect is non-scaling-stroke.
This means the stroke does not change with
scaling. The vector-effect is set to none at
20s. If something red gets visible,
an error occured.
Opera9.50 alpha interpretes the vector-effect, but if something is scaled to zero,
the stroke is not displayed anymore. Note that in the specification it is only noted for the
type matrix, if it is completely zero, that the display is disabled, not for other types or if
the resulting matrix is equal or not equal to zero...
Application example:
harmonic oscillator
Application: using vector-effect non-scaling-stroke and
animateTransform rotate to realise a one
dimensional harmonic oscillation.
A blue circle represents the harmonic
oscillator, the trajectory is displayed as
a gray path.
Comment: bug-286641
Severity: specification violation SVG tiny 1.2; regression compared with Opera 9.0x, 9.1x, 9.2x
Description: wrong path normalisation within animation
Example:
path animation with quadratic and cubic fragments
Path animation with different commands for bezier curves with
a dur of 10s. If something red gets visible an error occured.
Comment: bug-286637
Severity: crashes Opera 9.50 alpha/beta.
Description: A SVG document containing a beginEvent crashes Opera 9.50 alpha/beta
Example:
animation started with beginEvent
(show source code)
The crash happens sometimes immediately.
Comment: bug-286635
fixed in 9.50 alpha (build 1589)
crashes again in 9.50 beta (build 1834 for example)
Severity: crashes some versions of Opera 9.50.
Description: A SVG document containing foreignObject crashes Opera 9.50 (some builds).
Example:
animated foreignObject
(show source code)
The crash happens sometimes immediately or after a few seconds or if the tab containing the
document is closed.
Comment: Seems to be related to bug-278828, not send by me.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1.
Description: If some textPath elements are used within one text element, Opera adds an additional offset to the following text of the next textPath within the text element.
Example:
textPath elements in one text element
Three texPath elements for blue text are in one
text element. The difference in the paths is only
an offset in the y direction. No startOffset is given.
Therefore the three text fragments are on the
paths given in black and starting at the left.
Underlying red text show the correct positions for
comparison.
Comment: ok with the adobe plugin, KSVG1, Gecko1.8, Inkscape. bug-278846
partly fixed in 9.50 alpha (build 1567)
Severity: annoying only (but NO specification violation).
Description: If a large path is stroked in a document, the animation interpolation quality is very poor to unusable
Example 1:
large path and animateTransform with only a few values
animateTransform and a long fractal path. The path is
related to the Lorenz attractor.
The buttons bottom right do the following after clicking:
red: set the stroke of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation
Example 2:
large path and animateMotion
animateMotion along a long fractal path. The path is
related to the Lorenz attractor.
The buttons bottom right do the following after clicking:
red: set the stroke of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation
Example 3:
large path and animateTransform with a long values list
animateTransform along a long fractal trajectory. The trajectory is
related to the Lorenz attractor.
The buttons bottom right do the following after clicking:
red: set the stroke of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation
Example 4:
large path stroked
animateMotion along a long fractal path. The path is
related to the Lorenz attractor.
The path itself is stroked/painted using a stroke-dasharray
animation.
The buttons bottom right do the following after clicking:
red: set the stroke and the stroke-dasharray of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation
This one is still a problem for Opera9.50 - very rough interpolation.
Application:
Lorenz Attractor, random start and view
Animation of the Lorenz-Attractor.
The buttons bottom right (or the related GET parameters)
can be used to influence, wether the animation continues manually
or automatically or if it restarts.
In case of need the GET parameters can be used to define the
start position and other parameters. s is a parameter for scaling,
dur the duration in seconds (optional anz the number of animation points,
per default 20*dur).
Differential equation:
dx/dt = k(y-x)
dy/dt = l x - y - x z
dz/dt = x y - m z
The problem is rotated with an angle o (in degree) around the direction (x, y, z).
The animation quality is in all examples very poor, if the path is stroked. If the stroke is set to none with the red button, the quality is ok again. This indicates, that the problem is more related to the path itself and not to a specific animation. In comparison: the adobe plugin manages the situation without any problems except the missing stroke-dasharray animation in the example 4 and the application of course. This is clearly improved in Opera 9.50 alpha.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny.
Description: set or animate animations are not removed for pathLength in Opera9 after the active duration if no static value is given.
Example:
pathLength set or animate
If the red path with explicitely given static pathLength is not always
covered with the blue path without explicitely given static pathLength,
and error has occured. bug-269203.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny.
Description: accumulate sum has influence on not repeating animateTransform rotate. (Regression compared with Opera 9tp1. No animation in Opera8.x, wrong since Opera9tp2) .
Example:
animateTransform rotate with accumulate but without repetition
The attribute accumulate cannot have influence on a non repeating animation.
In Opera it has for animateTransform rotate. The blue test circle has another behaviour as the two red
comparisions, showing correct behaviour without accumulate attribute or
decomposed in three animateTransform.
Comment: ok with the adobe plugin and with Opera9tp1. bug-265720.
Severity: specification violation SVG 1.1 tiny.
Description: circle stroked as a square in Opera.
Examples:
simple blue circle between two thin black circles
Well, lets go back to the basics - lets stroke a simple circle. It uses number values from the number range of SVG 1.1 tiny
or from the even more restrictive SVG 1.2 tiny. What do we get in Opera? - A squared surprise!
But we can do it better:
simple blue circle between two thin black circles
Accuracy of rendering is tested using a circle.
For the tiny profile a number range from
-32767.9999 to +32767.9999 has to be supported
and the rendering accuracy has to be within one
device pixel.
The blue circle has to cover the red circle always
completely. The blue circle is completely inside the
large black circle and outside the small black circle.
Comment: First example works in Geckos 1.8 (SeaMonkey), second has an irregular doughnut as result. Konqueror+KSVG1 or Inkscape: First example ok, second a little bit shifted but wellformed circle. Adobe plugin: First ok too, with the second it gets interesting, it is not just irregular, it is cut! Gimp2.2: both examples ok. bug-263655
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny.
Description: stroked path fragments are not displayed if they are behind a subpath with zero length.
Example:
simple stroked paths
A path with length zero has to be painted as
a circle, if stroke-linecap is round.
The blue paths cover the red paths completely.
Opera does not display the path fragments of zero length (already reported as bug-196705)
and additionally does not display the path fragments behind this point (new).
Comment: ok with die adobe plugin. bug-260792.
In Opera9.50 alpha the problem with the following path fragment is solved, not the
display of the path fragments of zero length itself, but this is bug-196705.
Severity: specification violation SVG 1.1 tiny.
Description: stroked circle, ellipse or rectangle with rounded corners displayed wrong, if the size gets smaller than the stroke-width.
Examples:
stroked circles
stroked ellipses
stroked rectangles with rounded corners
- detailed descriptions in the desc element.
Comment: Problems with this in many viewers. Except for the animation subtest the best
results I have seen are from Mozilla with the current Geckos 1.8 (SeaMonkey, Firefox),
wrong in the adobe plugin and KSVG1 too, stroke is always a surprise in Amaya 9, in general
we get some very creative interpretations from different viewers.
bug-259672
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny.
Description: wrong font-size with stroke="none".
Example:
font-size and stroke="none":
Different X with the same size but different fill and stroke and stroke-width are
compared. With stroke="none" there is a wrong huge red X in Opera9, this should be
hidden behind a cyan one completely. A gray square with the same size as the
font-size is given for comparison.
Fits to bug-227771, not send by me.
Severity: specification violation SVG 1.1 tiny. Regression compared to Opera 8.x
Description: animateMotion confused by explicitely given pathLength. Regression compared to Opera 8.x.
Example:
animateMotion confused with pathLength:
Rectangles are moved along the same paths with animateMotion
with repetition.
For each path the pathLength is explicitely given. The correct
pathLength of 2400 is used for the blue rectangle, for the red
rectangles the given guess for the pathLength is 10% bigger or
smaller or animated between these guesses.
The motion has to be paced without any jumps or stops.
And because there are no other restrictions the motion has to go
along the complete path.
A given pathLength attribute for the path used for animateMotion
confuses Opera9. Either the velocity of the motion gets to fast or too
slow. Some errors are reduced in Opera9.50 alpha, but some are still
remaining.
Comment: It is pretty nice that Opera9 supports the attribute pathLength, but in this situation as given in the
example, pathLength has no visible effect on animateMotion, because the intrinsic behaviour of animateMotion
hides the effect of a corrected pathLength again. Ok in Opera8 and in the adobe plugin, but this
is no surprise, because they ignore pathLength in general even if it should have a visible effect ;o)
bug-250326
Severity: specification violation SVG 1.1 tiny or full.
Description: different wrong or confused timing for linear and spline animateMotion. Different hehaviour in different builds from Opera8 or Opera9, but always wrong.
Examples only for behaviour still wrong in Opera 9.10 and later:
Example 1:
linear animateMotion for paths with Z command:
Comparing linear animateMotion with animateTransform
for a rectangle.
animateTransform is blue and covers completely
the red animateMotion. Dark red uses the mpath element,
light red the path attribute and red values
The path consists of a triangle indicated in gray.
The paths are using explicitely the command Z to close
the path. In a linear animation the Z command consumes
time too, even if the length of the subpath is zero.
If something red gets visible, an error is occured.
Ok in Opera9.50 alpha.
Example 2:
linear animateMotion for paths with M command:
Comparing linear animateMotion with animateTransform
for a rectangle.
animateTransform is blue and covers completely
the red animateMotion. Dark red uses the mpath element,
light red the path attribute and red values.
The path consists of three simple lines as subpaths indicated in gray.
Except the initial M command the other M commands do not count
for the timing of the linear animation.
If something red gets visible, an error is occured.
Example 3:
linear animateMotion with elliptical arcs, SVG 1.1 full only:
Comparing linear animateMotion with animateTransform
for a circle as a path for a rectangle.
animateTransform is red and covered completely
by the blue animateMotion.
The path consists of three parts respectively two
rotations of 90 degree and a final of 180 degree
back to the initial position.
The paths are indicated in gray.
If something red gets visible, an error is occured.
Example 4:
spline animateMotion with elliptical arcs, SVG 1.1 full only:
Comparing animateMotion with animateTransform
for a circle as a path for a rectangle.
animateTransform is red and covered completely
by the blue animateMotion.
The path consists of three parts respectively two
rotations of 90 degree and a final of 180 degree
back to the initial position.
The paths are indicated in gray.
If something red gets visible, an error is occured.
Example 5:
spline animateMotion for paths with Z command:
Comparing spline animateMotion with animateTransform
for a rectangle.
animateTransform is blue and covers completely
the red animateMotion. Dark red uses the mpath element,
light red the path attribute and red values
The path consists of a triangle indicated in gray.
The paths are using explicitely the command Z to close
the path. In a linear animation the Z command consumes
time too, even if the length of the subpath is zero.
If something red gets visible, an error is occured.
Ok in Opera9.50 alpha.
Comment: Ok in the adobe plugin.
bug-249617.
fixed in 9.50 alpha (build 1567)
Severity: crashes/freezes Opera9 (tested with builds 434 and 466).
Description: A combination of small values in stroke-dasharray and huge pathLength crashes/freezes Opera.
Example:
stroke-dasharray and huge pathLength
(show source code):
The combination of small values in stroke-dasharray and a large pathLength
crashes/freezes Opera9 (tested with build 434 and 466).
Of course, this example is not very useful, similar crashes occured with much more
complex dynamic generated files using PHP - calculating the huge trajectory of
chaotic attraktors - numeric solutions of differential equations. Because the
attractor is chaotic and sometimes divergent, the trajectory can get very long,
if stroke-dasharray is animated to get the visible effect of the real-time
painting of the trajectory pathLength is used. This crash situation may occur if
authors test their number-cruncher scripts, hopefully not in tested applications
anymore.
In general if an author tries to animate trajectories or tries to display approximations
of fractal curves or something like this (with a fractal dimension larger than 1),
the pathLength can become very long in a finite area of a SVG document.
bug-236385
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny.
Description: Wrong inheritance for stroke-dasharray. Slightly different hehaviour in different builds from Opera8 or Opera9, but always wrong.
Example:
inheritance of stroke-dasharray tested:
Inheritance of stroke-dasharray is tested.
Correct result: One blue line, no RED visible!
Opera seems to inherit the stroke-dasharray more or less from the previous element not from the
parent element.
Comment: stroke-dasharray in Opera (and the specifications) is an annoying nightmare -
authors can rely to be fooled either by the viewers or the specifications, if they try to use it.
Ok in SeaMonkey/Firefox (Gecko1.8), Inkscape, KSVG1 and almost ok in the adobe plugin,
wrong in Amaya9.51, Gimp, imagemagick and several others...
The next bug (bug-229923) is maybe related. bug-230510
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny.
Description: If an element inherits none as a value for stroke-dasharray, the animation of this property for this element is ignored. Regression compared to Opera9tp1. Wrong since Opera9tp2.
Example:
animated stroke-dasharray:
A rectangle inherits the stroke-dasharray from
a g element. But the properties is animated for the element
directly. This overwrites the inherited underlying value 'none'.
Opera does not animate stroke-dasharray, the rectangle is alwayse stroked completely.
bug-229923
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny
Description: wrong final value for frozen cumulative animateMotion.
Example:
accumulative animationMotion:
Two circles are moved along squares given with
values, repeatDur and accumulate with a duration of 15s and repetition.
If the red center of the circle becomes visible, an error
occured.
Opera has a wrong final value for the frozen cumulative animateMotion.
Comment: Ok with the adobe plugin. bug-229920.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny and SMIL
Description: min attribute wrong interpreted.
Example:
min attribute in a simple animation
Simple from to animations for cx and cy of a
circle are used with min attributes and correlated
with syncbase values.
The gray path gives the correct trajectory.
If something red becomes visible, an error
occured.
Opera 9 repeats the animation until the min values is reached, but the user-agent
has just to correct the active duration to the min value without any visible effect for the
related animation. The effect becomes only visible for the correlated animations
in this case. There is no reason to repeat.
Combined with the end attribute there are some more errors.
See SMIL animation recommendation (or the same behaviour but better desription
in SMIL 2.1) about the min attribute and the determination of the active duration
of an animation.
Comment: See related (bug-185987) min and max.
bug-229915
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny
Description: Opera 8 and 9 all builds do not display text if title element or a comment inside before text content.
Example:
text with title, desc or comment
Opera does not display text, if the title element or a comment is directly before the text.
If blue text is red an error is occured.
Comment: works for example with the adobe plugin or with KSVG 1. bug-227467.
fixed in build 419
Severity: Crashes with Opera 8 and 9 up to 9.01 (400).
Description: Some combinations of nasty animateTransforms crash Opera.
Examples:
crashing Opera 9.01
(show source code)
crashing Opera 8 and 9
(show source code)
The second examples has a few seconds entertainment before crashing - maybe a hint,
why it happens. Originally I reduced it to the first example, but maybe the second
contains more information about the error - maybe an owerflow for large or indefinite
numbers in transformed objects (skewX=90)? bug-227466.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny
Description: Opera 9 does not inherit events for some special situations with use.
Example 1:
use and events
A gray rectangle on the left with a blue stroke is referred by a use element.
With a mouseover/mouseout the fill is set to dark blue.
The fill of the other light blue rectangle on the right is set to
dark blue with a mouseover/mouseout of the use element.
Example 2:
use and events
A rectangle with a blue stroke is referred by a use element.
With a mouseover/mouseout the stroke is set to light blue.
The fill of the rectangle is set to dark blue with a
mouseover/mouseout of the use element.
Comment: The adobe plugin and Opera9tp1 changes only the fill of the right rectangle of the first example, this is the other variant of the same error. In the second example the order of the set animations is changed and there the respective event is ignored. bug-227464.
fixed in 9.50 alpha (build 1567)
Severity: Severity: specification violation SVG 1.1 tiny and SMIL animation
Description: Opera starts an animation containing only end values before begin.
Example 1:
end before begin
The radius of a circle is animated with a
duration of 20s after 3s with the begin value,
the given end value is already 0s.
This results in no animation, because
the end-value before begin without any
end value after begin prevents the animation
from starting.
If something red becomes visible, an error
occured.
Comment: The behaviour of the adobe plugin or of KSVG1 is wrong too. My primary understanding of this situation was consistent with the behaviour of the adobe plugin, KSVG1 and Opera, but after a discussion in the SMIL mail archive it turned out, that this behaviour is wrong. Another misunderstanding is suggested by a wrong informative test about restarting and event based begin and end values. bug-227463.
fixed in 9.50 alpha (build 1567)
Severity: Crashes Opera9 since tp1.
Description: calcMode paced for the animation of the d attribute of a path crashes Opera9 in all builds. Since build 419 Opera is just frozen - not really an improvement...
Examples:
crashing Opera 9 with a paced quadratic path animation
(show source code)
crashing Opera 9 with a paced qubic path animation
(show source code)
Ok - calcMode paced is for paths not really defined in SVG1.1,
because there is no distance definition in SVG1.1 and the distance
definition of the SVG1.2mobile working draft is quite useless and inconsistent with SMIL,
but this is no reason to crash, as Opera9 does in all builds since
tp1. bug-223683.
Animation ignored in Opera9.50 alpha. This is ok, because there is no specified
behaviour for such a paced animation.
Severity: specification violation SVG 1.1 full or basic.
Description: writing-mode and glyph-orientation-* for several glyphs wrong or ignored, direction wrong.
Examples:
testing writing-mode tb-rl and glyph-orientation-vertical
testing writing-mode rl-tb, glyph-orientation-horizontal,
unicode-bidi, direction:
With the blue buttons the font-size or the font-family can be animated (see title elements). Errors depend on the font-family.
Only generic font-families are used.
Comment: compare with the behaviour of the adobe plugin. I think it is correct except the fact, that the adobe plugin ignores several generic font-families. bug-223007.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny, full or basic.
Description: Opera9 (all builds since tp2) ignores some values of a values-animation of xlink:href, if there is some white space near the semicolon separators.
Examples:
values-animation of xlink:href of use (tiny),
values-animation of xlink:href of tref (full):
Using the use or tref element it is counted from 0 to 9 with repetition.
Each second one count. All text is blue. If red text gets visible, an error
occured, because the red text is always and completely covered by
the same text in blue. If not all numbers are counted or the counting
stops, is an error occured, this is not always reproducable.
Sometimes it needs several attempts to stop the counting with Opera.
Why Opera stops is not clear.
The main error is anyway, that Opera does not display some identifiers,
if there is additional white space, as allowed by SMIL animation
recommendation 3.2.2:
'Leading and trailing white space, and white space before and
after semicolon separators, will be ignored.'
Comment: No problem with the adobe plugin. bug-223004.
fixed in build 395
Severity: Crashes Opera9 since tp1 or tp2.
Description: If a pattern is referenced in such a way, that it has do be applied directly or indirectly to itself, Opera9 crashes.
Minimal example
(Crashes since Opera9tp1,
show source code).
This does not happen, if the pattern is applied to a rectangle inside the pattern:
No crash with smaller changes.
But a little bit more complex it crashes again:
some recursive loop
(Crashes since Opera9tp2,
show source code).
This does not happen, if the patternContentUnits are objectBoundingBox:
recursive loop without a crash
(Opera renders the recursive part in black).
Comment:
Of course there is not way, to render these recursive pattern correctly, this seems to be a gap
in the SVG specification. Anyway a viewer should not crash. With similar examples KSVG1 has
similar problems. Most other browser I tested or if the viewer does not crash do not render
the complete recursive pattern or just not the recursive path.
Open question: Are there more crashes in similar situations with symbol, marker, mask, clip, use
defined recursively? I did not test this yet. bug-220838.
Severity: specification violation SVG 1.1 full or basic (regression compared to Opera9tp1 build 1428).
Description: Wrong display of dashes in a masked path. Worked already in Opera9tp1.
Example:
stroke-dasharray and masked path:
Note, that stroke-linecap is butt for the stroked path.
Even if linecaps are applied to the end of dashes, butt is
not round. This seems to be somehow inherited from the
mask, but there is no reason to do it, because the path
in the mask has no stroke-dasharray and there is no
reason for inheritance from or into a mask referenced
with the mask attribute. The mask just rounds the
caps of the complete path.
Animation of stroke-dashoffset and of
stroke-dasharray with a click on the blue buttons is
just added to see the general behaviour for different
values of dashing.
Comment: Maybe related: 2006-06-24:01, bug-216714. bug-219441.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 (regression compared to Opera9 up to build 300).
Description: no display if radius of feMorphology is animated. Wrong since build 320 including Opera9.00 (build 344) and later builds.
Example:
animate operator and radius of feMorphology:
operator and radius of feMorphology are animated.
First operator is erode and radius is animated from
1 1 to 10 5 in 10s starting at 2s.
Then operator is set to dilate and the
animation of radius is repeated. bug-216718.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic and full (regression to compared Opera9 up to build 300).
Description: no display if stdDeviation of feGaussianBlur is animated. Wrong since build 320 including Opera9.00 (build 344) and later builds.
Example:
animate stdDeviation of feGaussianBlur:
stdDeviation of feGaussianBlur is animated after 3s for 30s and is frozen.
The initial stdDeviation is .04 .04. The values are:
0.2 0.1; 0.1 0.2; 0.05 0.07; 0.01 0.02; 0.003 0.00001; 0 0; 0 0; 0.01 0.02; 0.1 0.1; 0.3 0.2; 0.4 0.3; 1 2; 5 3.
The width of the graphic is 1 for comparison. bug-216717.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 (regression compared to Opera9 up to build 300).
Description: no horizontal turbulence or no display (since build 387) if baseFrequency of feTurbulence is animated. Wrong since build 320 including Opera9.00 (build 344) and later builds.
Example:
animate baseFrequency of feTurbulence:
baseFrequency of feTurbulence is animated
in 10s starting after 2s, resulting in several images. bug-216716.
fixed in build 387
Severity: specification violation SVG 1.1 tiny (regression compared to Opera9 up to build 300).
Description: wrong animation of stroke-dasharray. Wrong stroke-dasharray in animation since build 320 including Opera9.00 (build 344) and later builds. Previous builds have just minor painting problems in the edges, but animate correct.
Example:
animation of stroke-dasharray:
Light gray is the initial stroke-dasharray, medium gray
the final with other stroke-width and dark gray is
the final value with the same stroke-width. bug-216714.
Severity: specification violation SVG 1.1 tiny (regression compared to Opera8).
Description: text x and y animations are not additive. Different errors in different versions of Opera9 - either the lower priority animations are ignored or the higher priority animations are ignored as in Opera9.00.
Example:
additive animations of x and y of text:
Two from to animations are added with additive sum for
x and y of text. The visible result is that the blue 'text'
covers exactly the red 'text' without any visible animation
effect. If something red is getting visible, an error occured.
Note that x and y for each glyph are of the type coordinate. And this type supports additive animation.
Comment: works with the adobe plugin and with Opera8 (not under all conditions, but for this example). bug-216720.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic or full.
Description: use inside mask element ignored
Example:
use inside mask element:
A mask element and a path referenced by a use elements
are chosen to define a mask for the same path to be
painted. The visual effect of the animation is, that
for 3s only the outer part of the stroke is visible and
for the other 3s just the inner part including fill, for
another 3s no mask is used.
Click object to set stroke to none for 3s.
Opera does not display the path referenced with use for the
first 3s, but is able to use the path if directly used for masked.
Specification says, that use is an allowed child of mask.
Comment: works with the adobe plugin. bug-214538.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny.
Description: time intervals are calculated wrong for discrete animations without keyTimes
Example:
discrete animations with and without keyTimes:
SVG and SMIL have a well defined timing interval
model. Time intervals are always in such a way defined,
that the initial given point in time belongs to the interval and
the final given point does not belong to the interval.
This means, in this example with
values="100; 350; 600; 850"
keyTimes="0;0.25;0.5;0.75"
dur="12s"
begin="0s"
end="9s"
begin and end define a time interval, this means,
the interval starts with included 0s and ends with excluded 9s.
Therefore the final presentation value is 600 and not 850.
Note, that the keyTimes are the same as calculated
automatically without using keyTimes.
The cx of a circle is animated discrete from left to right with
some values and keyTimes and a duration of 12s, but an
end already at 9s.
This animation is superposed by a simple from to
animation from top to bottom. The visible effect is
a motion along the given gray path.
If something red becomes visible, an error
occured.
The automatically calculated time intervals of Opera do not exclude the final value
and therefore the wrong value is displayed at 9s and later for this animation.
Comment: OK with the adobe plugin. bug-214535.
fixed in build 387
Severity: specification violation SVG 1.1 basic or full (regression compared to builds earlier as 272).
Description: fill without stroke for tspan ignored by Opera9 since build 272.
Example:
tspan property fill:
The initial 't' of the large 'text' is set to fill="#00f" with a tspan.
Since build 272 the fill is only blue, if the stroke is given too. Just for
testing this can be done here with hover or click on the 'text'. bug-212136
Severity: specification violation SVG 1.1 basic or full (regression compared to Opera 9tp2).
Description: Opera9 later builds as tp2 ignore transformed views as a target of an a element. Regression compared to Opera 9tp2. Wrong behaviour and strange residuals in Opera9.50 alpha.
Example:
referencing a transformed view:
Four transformed views are given directly with SVG specific fragment identifiers
as targets of an animated xlink:href attribute
of an a element. Colours are changed just to give a timing.
Click on the circle to see the target view. bug-211239
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 full (regression compared to Opera 9 up to beta1).
Description: Opera9 build 256 does not animate an elliptical arc path continuously, later builds have a wrong continuous animation. Build 320 only displays the final path at the end. Regression compared to builds up to beta1 (236).
Example 1:
animation of an elliptical arc path:
animate animation test of a specific attribute of the path-element:
d (represented by a blue curve)
changes from the dark gray curve to the light gray curve in 10s.
The yellow and orange circles belong to the initial
curve and the cyan and cyan-green circles belong
to the final curve.
d contains the commands M, A, a
corresponding to elliptical arcs.
The same flags are used for easier animation.
The animated path is constructed with two elliptical arcs paths, therefore it has
exactly two ends and one corner where the two arcs join together.
Builds 272 and later have more corners, initial and final path are correct, but the
animation between is nonsense, consisting of four (?) elliptical arcs.
Example 2:
animation of an elliptical arc path:
animate animation test of a specific attribute of the path-element:
d (represented by a blue curve)
changes from the dark gray curve to the light gray curve in 10s.
The yellow and orange circles belong to the initial
curve and the cyan and cyan-green circles belong
to the final curve.
d contains the commands M, A, a
corresponding to elliptical arcs.
The animated path is constructed with two elliptical arcs paths, therefore it has
exactly two ends and one corner where the two arcs join together.
Builds 272 and later have more corners, initial and final path are correct, but the
animation between is nonsense, consisting of four (?) elliptical arcs.
Note that flags are changing between 0 and 1 because these are integers, their
animations is discrecte, causing a simple jump. The other parameters are animated
continously.
Comment: This regression is a little bit surprising. Ok, this is not tiny or basic, but worked already pretty good in several builds and the documentation claims, that the path element is supported. bug-211231.
Severity: specification violation SVG 1.1 tiny
Description: Opera8 and Opera9tp1 do not animate animateTransform using to, wrong animation in Opera9tp2, different wrong animation in Opera9beta1 and later versions.
Example 1:
animateTransform using to:
Two blue circles are moved to one position marked
with a gray circle, using animateTransform with to
for a translation to the absolute final value.
Two red circles are animated as simple references just
for comparison. If the red circles become visible,
the animation of the blue circles is wrong.
Note that to animations have a special additive
behaviour, defined in detail into the SMIL
recommendation, which overwrites die additive
attribute. Opera does something different and
uses the value of the additive attribute somehow.
Ok in Opera9.50 alpha.
Example 2:
animateMotion using to:
similar as example 1.
Example 3:
animateTransform using to:
A blue square and a test text are transfomed with a matrix.
After 3s an animateTransform with a scale to -1,1 and
a duration of 10s and calcMode linear is applied to the group.
This means, after 3s the group morphes to a mirrored
group continuously.
matrix itself is not animatable, but it is the initial
value for the animateTransform.
If a red group becomes visible, an error occured.
The problem with this example is, that in the SVG specification it is not mentioned,
that the type matrix is animatable, unfortunately this seems to be needed to get the
correct result in general. Of course for this example it is simpler, because the initial
transformation is just a scaling.
To get the to-animation correct, a special rule has to be used.
If C(t) is the current transform matrix and T the to value of the
animation represented as a matrix, t the time, d the duration, the Opera can use additive replace and the following transform matrix for a to-animation:
C(t) + (T - C(t))* t/d.
In many cases it is possible to define this as a multiplicative
matrix with additive sum too, but then the inverse matrix
of C or T has to exist. Just for scaling the inverse of T
exists not alway, this happens, if the scaling factor for x
or y is zero. Therefore the formular above is much simpler.
If C(t)-1 exists, the
following formular can be used for an additive sum animation
(I is the identity transformation):
I* (1-t/d)+ C(t)-1F*t/d
If F-1 exists, F can be used as the
initial value and the formular is:
I * t/d + (1- t/d) F-1C(t)
Comment: This example is wrong in the adobe plugin too, it trys a discrete animation with the
correct final value and crashes a moment later.
Note, that this problem is not related with the SVG1.2 mobile working draft problem mentioned in
2006-05-14:01, because to-animations are clearly excluded in the
concerning part of the working draft.
bug-212137.
Another unsolved problem without any changes since Opera9tp1 with to-animation is 2005-10-18:01 (bug-185982).
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 tiny (in parts regression compared to Opera9tp1)
Description: Opera9 (tp2 and later) has a wrong interpretation of animateTransform using by. The animation is not additive.
Example 1:
animateTransform using by:
A blue circle is moved from right to left in 5s
using animateTransform with the by attribute.
Because for by the animation is additive, the
initial transformation is not overwritten.
If the red circle gets visible, an error occured.
Example 2:
animateTransform using by:
A blue square and a test text are transfomed with a matrix.
After 3s an additive animateTransform with a scale by -1.5,-1.5 and
a duration of 10s and calcMode linear is applied to the blue group.
This means, after 3s the group morphes to a mirrored
group.
matrix itself is not animatable, but it is the underlying
value for the animateTransform.
If a red group becomes visible, an error occured.
(not animated in Opera 8 and 9tp1)
Comment: Note, that for these examples the animation is the same as an additive from-by-animation with
the identity matrix as the value of the from. First example ok with the adobe plugin, the second is wrong too
with the adobe plugin, this uses the zero matrix as the initial value of the animation.
There are some problems with animateTransform in the working draft of SVG1.2 mobile for the additive
behaviour of animateTransform. At the moment the working draft is not consistent with SMIL and not
self consistend. Anyway the given situation for SVG1.1 (full, basic, tiny) is quite clear with the current
specification, therefore this examples for SVG 1.1 have a well defined behaviour.
The problems with the working draft are already reported to the W3C SVG working group. bug-212139.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic or full
(Styling with CSS is optional in the basic profile)
Description: Opera9 beta1 and later versions animate the class attribute wrong. In the Opera Documentation of Opera 9 beta it is claimed, that class is supported.
Example 1:
set animation of the class attribute:
The class attribute is changed from s1 to s2
for the top rectangle and from s2 to s1 for the
bottom rectangle after 3 seconds. The displayed
rectangle changes the properties fill, stroke, stroke-width,
opacity, stroke-opacity and fill-opacity.
This means as a visual effect the exchange of the styling
between the top and the bottom rectangle.
Opera shows the rectangles black, this means, the result of the
animation is ignored.
Example 2:
set animation of the class attribute:
The class attribute is changed between two class lists
after 3 seconds. The displayed rectangle
changes the properties fill, stroke, stroke-width,
stroke-opacity and fill-opacity.
bug-208531
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic or full.
Description: Opera9 beta1 and later versions do not animate attributes of the mask element
Example 1:
animation of mask:
x, y, width and height are animated within 12s.
This changes mainly the size of the visible part of the masked element.
Example 2:
animation of mask:
maskUnits is animated from objectBoundingBox to userSpaceOnUse after 3s.
This changes mainly the size of the shape as a visible effect.
Comment: Ok in the adobe plugin. bug-208528.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic or full.
Description: Opera9tp2 and beta1 and builds up to 300 display a linear animation of baseline-shift as discrete animation. Build 320 and later ignore the property completely for animation.
Example:
linear animation of baseline-shift:
baseline-shift changes from -100 to 100
in 3s. If something red is getting visible,
an error occured.
Comment: ok with the adobe plugin. bug-206019.
fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic or full.
Description: Opera9 beta 1 and all builds since tp2 display small negative letter-spacing wrong.
Example:
letter-spacing animation:
letter-spacing changes from -60 to 10 with a duration of 10s.
Final and initial glyph arrangements are given
in gray (for initial just a guess, not calculated).
Comment: ok with KSVG 1 and the adobe plugin. bug-205819.
no crash and no display since build 272
fixed with display in 9.50 alpha (build 1567)
Severity: crashes Opera 9 beta1 and later builds, specification violation SVG 1.1 basic or full.
Description: Opera9 beta1 crashes with text-anchor middle and small negative letter-spacing, build 272 has no display.
Example:
crashes Opera 9 beta1,
(show source code).
bug-205822.
partly fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic or full.
Description: Opera9 beta1 and later builds has a wrong interpretation of the dx and dy attributes for text. If a list is used, the values are not incremental, the are used for each glyph relative to its initial position and not incremental or relative to the current text position. Linear animation is misinterpreted as discrete animation.
First Example:
animated dx and dy attributes for text:
dx and dy attributes are set from 0 to 40 after 3s for the top text.
dx and dy attributes are set from 0 to 40 60 80 100 after 3s for the bottom text.
The gray 'text' displays the correct final position of the top text, the gray 't'
displays the final position of the last t of the bottom 'text'.
Ok in Opera9.50 alpha.
Second Example:
animate dx and dy attributes for text:
dx and dy attributes change continuously from 0 to 40 in 5s for the top text.
dx and dy attributes change continuously 0 to 40 60 80 100 in 5s for the bottom text.
This means, the first text moves a little bit right down.
In the second text each glyph moves a little bit right down relative
to its predecessor.
The gray 'text' displays the correct final position of the top text, the gray 't'
displays the final position of the last t of the bottom 'text'.
Discrete animation in Opera9.50 alpha.
Comment: Opera9 interpretes this attributes since tp1 in this way, before it was ignored, but from Opera 9 beta1 a correct interpretation of these basic attributes can be expected. Correct display with the adobe plugin, no interpretation for lists with KSVG1. bug-205738 (just for text).
partly fixed in 9.50 alpha (build 1629)
Severity: specification violation SVG 1.1 tiny.
Description: Opera8.x ignores the foreignObject, Opera9 does not show the content of foreignObject but animates it since Opera9tp2. Build 256 does not show anything and does not animate.
Example:
foreignObject element:
animate animation of specific attributes
of the foreignObject element. The foreignObject
contains a small XHTML document containing a small blue circle
from SVG.
x and y change from 500 to 100 in 10s.
width and height change from 400 to 700 in 10s.
The initial dimensions of the foreignObject are given with a
light gray stroked rectangle, the final dimensions are given with a
dark gray stroked rectangle.
9.50 alpha (build 1629) displays and animates the XHTML, but does not
display the SVG inside XHTML.
Comment: Note, that the doctype is for XHTML+MathML+SVG because as far
as I know, it is not possible to generate a valid document with another doctype.
Anyway foreignObject is defined for SVG tiny.
What should happen, depends on the xhtml abilities of the user-agent. If it knows xhtml, it should display
both xhtml and the circle from SVG, if not, it should display the circle as a minimum.
The animation is applied to the foreignObject. This moves the circle and the xhtml as a visible effect.
The animation of the foreignObject is ok, if the SVG circle is visible and moves.
Related bug number from opera forum for another example (not send by me): bug-205048
partly fixed in 9.50 alpha (build 1567)
fixed in 9.50 alpha (build 1589)
Severity: specification violation SVG 1.1 basic and full.
Description: Opera 9 beta 1 and later builds, published to be able to support the basic profile does not display a svg document referenced with the image element. Opera 9.50 alpha displays it, but does not animate.
Example:
animated svg document referenced with an image element
The animated SVG svgxy01.svg is referenced with the
image element. The border of the image is given with a blue stroked
rectangle. In the referenced document a blue rectangle and circle is set from top left to bottom right.
bug-205735
Severity: Regression of 181, 197, 225, 229, 236, 256 compared to 1670 and older and specification violation SVG 1.1 tiny.
Description: Wrong close path behaviour with closed subpaths and stroke-dasharray.
Simple examples:
two rectangles as two closed subpaths
A path is composed out of two closed supaths, representing
two squares.
This works without stroke-dasharray, but with stroke-dasharray Opera9
(builds 181, 197, 225, 229, 236 fail, ok up to 1670, which have other errors
explained in other errors reports) presents something different.
If something red is getting visible, an error occured.
Looks like a wrong close from the second z to the first
M, ignoring that this path contains two subpathes, each
of them closed separately. Note that stroke-dasharray is
only a stroke pattern, this means, it is not possible that
it is outside the stroke.
bug-203951
Severity: Crash of builds for example 181, 197, 225, 229, 236, 256 and specification violation SVG 1.1 (full or basic).
No crash anymore with build 272, but still ignored.
Description: Animation of font-size-adjust or font and other unsupported properties crashes several Opera9 versions. Output on konsole: Segmentation fault.
Simple examples:
set animation with font-size-adjust
- works with animate too.
(show source code)
set animation with font
- works with animate too.
(show source code)
set animation with font - optional bonus
example- support not required for a conforming svg viewer, but should not crash ;o).
(show source code)
Added further animation crashes, tested with 229: kerning, color-rendering, color-interpolation, shape-rendering, text-rendering, color-interpolation-filters.
Comment: font-size-adjust works with the adobe plugin but font is incomplete. No crash up to build 1670. bug-203877.
almost fixed in build 272
Severity: Specification violation SVG 1.1 tiny.
Description: Opera 8.x and Opera 9tp1/2 up to build 256 do not animateColor with calcMode paced. Minor error in builds since 320.
Example:
animateColor and calcMode paced
The colour of a circle is animated with several
values. The duration is 10s and
the calcMode is paced, this results
in a slow change of colour from green to red to blue.
The colour of the stroke is animated with the
same values, but with keyTimes, resulting in the
same visual effect, therefore there is not visible
difference in the colours of fill and stroke.
The small circle bottom right shows a linear
animation with the same colours for comparison -
should be different except in some certain points in
time. OK since Opera 9 build 272.
Second example:
animateColor and calcMode paced
The colour of a circle is animated with several
values. The duration is 10s and
the calcMode is paced, this results
in a slow change of colour from green to red to blue.
The final value of fill is frozen and the same as for
stroke. Opera since build 272 freezes to a wrong final value.
Comment: The adobe plugin ignores the calcMode paced. bug-201913.
Severity: crashes Opera9tp2, specification violation SVG-tiny. beginEvent crashes Opera 9.50 alpha again...
Description: Opera9tp2 crashes with repeatEvent, beginEvent, endEvent. Other versions ignore these events.
Simple examples:
crash Opera9tp2 with repeatEvent
(show source code). (ok in Opera 9.50 alpha)
crash Opera9tp2 with beginEvent
(show source code).
crash Opera9tp2 with endEvent
(show source code).
If something red appears, the animation is wrong, for example because the events are ignored.
Comment: Reported to Opera as bug-196701 (only for repeatEvent).
fixed in 9.50 alpha (build 1567)
Severity: Specification violation SVG-tiny (regression compared to Opera9tp1).
Description: Opera9tp2 and later builds ignore begin event - clock value for begin, worked already with Opera9tp1. Since build 300 it works for the first event, but if a second event occurs before the animation is finished, not this and no further event lead to an animation.
Simple example:
begin event click - clock value for begin.
The begin of the animation is started 5s before
a click on the circle.
This starts a fill animation from black to white
of 10s duration. Of course the animation can't really
start 5s before the click. This means, the visible
animation has to start with gray and not black.
Opera9tp2 ignores it. In build 1670 it works almost,
but if a second click occurs, when the animation
is running, it stops to work. Ignored since build 181.
Another example:
begin event mouseover - clock value for begin.
The begin of the animation is started 5s before
a mouseover of the circle.
This starts a fill animation from black to white
of 10s duration. Of course the animation can't really
start 5s before the mouseover. This means, the visible
animation has to start with gray and not black.
Opera9tp2 ignores it. In build 1670 it works almost,
but if a second mouseover occurs, when the animation
is running, it stops to work. Ignored since build 181.
Another example:
begin event mousedown - clock value for begin.
The begin of the animation is started with
a mousedown on the circle. This starts a color animation
of 6s duration 3s before the mousedown. This means, the visible
animation has to start with gray and not black.
Opera9tp2 ignores it. In build 1670 it works almost,
but if a second mousedown occurs, when the animation
is running, it stops to work. Ignored since build 181.
Another example:
begin event mouseup - clock value for begin.
The begin of the animation is started 3s before
a mouseup on the circle. This starts a color animation
of 6s duration.This means, the visible
animation has to start with gray and not black.
Opera9tp2 ignores it. In build 1670 it works almost,
but if a second mousedown occurs, when the animation
is running, it stops to work. Ignored since build 181.
Another example:
begin event mouseout - clock value for begin.
The begin of the animation is started 3s before
a mouseout on the circle. This starts a color animation
of 6s duration. This means, the visible
animation has to start with gray and not black.
Opera9tp2 ignores it. In build 1670 it works almost,
but if a second mouseout occurs, when the animation
is running, it stops to work. Ignored since build 181.
Another example:
begin event mousemove - clock value for begin.
The begin of the animation is started 3s before
a mousemove on the circle. This starts a color animation
of 6s duration. This means, the visible
animation has to start with gray and not black.
Opera9tp2, builds 1670 and later builds ignore it.
Comment: First example worked already with Opera9tp1, the same problem with the adobe plugin,
does not work with activate and several other events, which are still completely ignored by Opera.
Reported to Opera as bug-196703.
fixed in 9.50 alpha (build 1567)
Severity: Specification violation SVG-tiny (regression compared to Opera9tp1).
Description: Opera9tp2 and later builds have a wrong interpretation of the activation of set animations with a elements. Opera9tp2 resolves the begin times for the repeated history of animations wrong, if the same animation is activated a second time.
Simple example set:
a elements and set.
With a click on one of the small circles on the top
the colour of a large circle is set.
Note, that a click on one small circle resolves the begin of the relating
set animation. The whole history is repeated after another click on the same
circle.
Opera 9tp2 is able to change the colour with the first click independent for which
colour, but then id works only for one circle right to the one clicked before (later in
the source code). Opera 9tp1 is able to show the correct behaviour.
Simple example animate and history:
a elements and animate.
A click on one of the magenta symbols gives
a by animation for a circle as expected intuitively by the type
of the symbol. fill is set to freeze, therefore the
animations stop at their end points.
Because by animations without from are additive, the start
of an animation depends on the history.
The first click on a symbol resolves the begin time for the
corresponding animation. If the symbol is clicked again,
all animations after the first click have to be repeated with
corresponding begin times.
(see SMIL animation recommendation for hyperlinking rules).
For example: If after one motion the opposite
direction is chosen, the motion starts at the final position
of the previous animation. If the same direction is chosen,
the animation has to start with the initial value for the
first click. This can
be the initial value of the same animation or the
final position of an previous animation in the opposite
direction, depending on the history. Anyway the history
since the last click on the same symbol has to be repeated.
If the animation is started, while itself is already running,
it has to start at the intial value. If it is started, while an
animation in the opposite direction is running, it is
additive, the visual effect is, that it stops until the other
animation is finished.
Animation for different attributes superpose always and
have no influence on each other.
Initial values for horizontal and vertical motions are given
as small circle and lines as a help.
Comment: No Problem with the Adobe plugin.
Reported to Opera as bug-196704 (just the first example).
Severity: Specification violation SVG-tiny.
Description: Opera9tp1/2 and later builds and Opera 8.x do not paint a path of length zero with line-cap round. See explanations for stroke in the SVG specification for the painting of such a path.
Simple example:
painting a path of length zero.
A path with length zero has to be painted as
a circle, if stroke-linecap is round.
The blue paths cover the red circles completely.
Comment: No problem with the adobe plugin, partly correct with Konqueror, and wrong with
Opera9tp1, Opera8.x, the Geckos like
Mozilla, SeaMonkey, Firefox etc, Gimp, Imagemagick and Inkscape.
Reported to Opera as bug-196705.
Severity: Specification violation SVG-tiny
Description:
Opera9tp1/2 and later builds and Opera8.x have a wrong rendering of basic shapes, which
becomes visible, if stroke-dasharray is applied to a basic shape.
At the initial and the final value of the path of the most basic shapes there is an additional
gap as error if stroke-dasharray is applied to the basic shape.
Often it is not very important, where the rendering of a basic shape
is started and where it ends, but of course for stroke-dasharray and
related properties it gets important. Therefore it is exactly defined
in the specification, which path represents a basic shape.
Simple examples:
stroke-dasharray rendering of a
rectangle.
The shape of the rectangle is given in red.
For a rectangle (with rounded corners) rendering starts with the
horizontal part at the top, marked here with a green arrow on a
green dash. The path end is marked with a magenta arrow on a
magenta dash. Note that there is no gap or overlap between
the green and the magenta dash.
The rendering of Opera goes from the final to the initial value of the
path and an additional gap becomes visible between these two values.
KSVG has the same errors, correct display with the adobe plugin.
The gap error occurs with serveral other user agents too, often the
path is correct, but not with all.
stroke-dasharray rendering of a
circle.
The shape of the circle is given in red.
For a circle rendering starts at the '3 o'clock' position, goes down to
6 and proceeds to 9 and forward to 12 and finally from 0 to 3 again.
The begin is marked here with a green arrow on a green dash.
The path end is marked with a magenta arrow on a magenta dash.
Note that there is no gap or overlap between the green and the
magenta dash.
The rendering of Opera goes from the final to the initial value of the
path and an additional gap becomes visible between these two values.
The adobe plugin has no gap, but the wrong initial point. KSVG has the
correct path, but the additional gap, the same for sodipodi and inkscape.
stroke-dasharray rendering of an
ellipse.
The shape of the ellipse is given in red.
For a circle rendering starts at the '3 o'clock' position, goes down to
6 and proceeds to 9 and forward to 12 and finally from 0 to 3 again.
The begin is marked here with a green arrow on a green dash.
The path end is marked with a magenta arrow on a magenta dash.
Note that there is no gap or overlap between the green and the
magenta dash.
The rendering of Opera goes from the final to the initial value of the
path and an additional gap becomes visible between these two values.
The adobe plugin has no gap, but the wrong initial point. KSVG has the
correct path, but the additional gap, the same for sodipodi and inkscape.
stroke-dasharray rendering of a
polygon.
The shape of the polygon is given in red.
The begin is marked here with a green arrow on a green dash.
The path end is marked with a magenta arrow on a magenta dash.
Note that polygon is a closed path and the magenta dash is much
longer than needed to cover the stroke-linejoin and the green dash has
a stroke-dashoffset long enough to cover the stroke-linejoin.
As far as I know, it is not defined, if the stroke-linejoin belongs to the
initial part of the path or the final, but maybe it would look
most suitable, if the stroke-linejoin is shared symmetrically between
the initial and final part. Alternatively and maybe easier for rendering:
The z command is at the end of the path, therefore the stroke-linejoin
can be completely painted at the end after the final value.
Here Opera has only the problem of the additional gap instead of
a stroke-linejoin with the z command. Similar problems with KSVG,
adobe plugin and other user agents.
Reported to Opera as bug-187204. Since Opera 9tp2 the rendering direction is correct, but there is still a gap at the end of the closed paths.
Severity: Specification violation SVG-tiny
Description: Opera9tp1/2 and later builds and Opera8.x interprete dashes of the paint property stroke-dasharray as subpathes and not as a pattern, leading to a wrong rendering of stroke-dasharray dashes and gaps.
Simple example:
rendering of the stroke-dasharray.
stroke-dasharray controls the pattern of dashes and gaps used to stroke paths.
dasharray contains a list of comma-separated lengths that specify the lengths
of alternating dashes and gaps.
Because dashes and gaps are defined as pattern, and not as subpaths, stroke-linecap
has not to be applied to the dashes or gaps, and dashes and gaps are just a
(one-dimensional) pattern inside the stroke and not outside.
The lengths of each dash and each gap is exactly
defined in the given list. Because it is a pattern, it will be repeated forward and backward
along the stroke an its linecaps.
For the red circle this means, nothing is outside the shape marked with thin black strokes.
In the center of the stroke, the dashes and the gaps both have a length of 100 and gaps
and dashes have the same shapes and sizes.
For the rectangle this means, the gaps are clearly visible and have the same length 100
as the dashes.
For the line this means, the linecaps are round, not the dashes themselves.
Depending on the stroke-dashoffset the linecaps might be not visible, because the
pattern in this area is a gap, but this can be controlled by the author with stroke-dashoffset.
The caps of the dashes and gaps are straight lines perpendicular to the stroke-direction given
by the path of the shape. Other caps for dashes or gaps are not defined in SVG 1.1 (both mobile or full).
If needed, this has to be added in a future version of SVG for example as stroke-dashcap, stroke-gapcap,
stroke-dashbegincap, stroke-dashendcap, stroke-gapbegincap, stroke-gapendcap
or maybe better stroke-dashpattern, in parts this is maybe already covered by the pattern element
(not part of tiny), which can be applied to the stroke in SVG 1.1.
Workaround for this simple example to show how it should look like: workaround.
Note, that there are additional errors, in parts not
directly visible in the example, but corrected here too -
use of the correct path for the rect and add the missing
bevel corner top left; use of the correct path for the
circle (therefore we have to go away from svg-tiny).
See comments in the source code for details.
Correct display of the workround for example with Opera, KSVG1, adobe-plugin, inkscape, imagemagick,
sodipodi.
Comment: Slightly different errors in KSVG 1 and the adobe plugin and many other user agents,
the circle is correct with inkscape, the rectangle almost correct with inkscape, which has unfortunately
the same error as Opera, already noted below as 2005-11-10:01, the dasharray itself is correct for the
rectangle, for the line it is wrong too for inkscape.
Reported to Opera as bug-186670.
Severity: Specification violation SVG-tiny
Description:
First problem: Opera 9tp1/2 and later builds and Opera 8.x display wrong pathes
for the begin of the initial and the end of the final part of the path of
quadratic and cubic curves.
Second problem: slopes in cubic pathes are displayed as corners. Together
with a wrong interpretation of the stroke-linejoin this causes wrong rendering
of the slopes.
First simple example for the first problem:
path rendering cubic path.
The cubic paths show the same continuosly differentiable path,
just the stroke-width differs. The initial and final points in the paths
are the same and the derivation at this points too.
Because the connection from the end point to the start point is
continuosly differentiable and this points are the same, it is
not necessary to finish the d attribute value with z to close the path.
Note, that the derivation of the red path is in the start and
end point perpendicular to the x-axis. This means, in both
cases the stroke starts exactly in y-direction and ends exactly
in the y-direction and in both cases the stroke-with is aligned
exactly in the x-direction. In this point additionally there are
no edges or corners, because the given curve is closed and
continuosly differentiable.
With Opera the paths are not closed, this looks like a wrong determination
of the derivation at the begin and at the end of the path and causes a
cascade of further problems, for example with stroke-dasharray, stroke-dashoffset
and with animation of this properties, whereat this problems are not easy to
correct as for this example (unfortunately I started at an end of the problem cascade
and had a long way to this cause).
Second simple example for the first problem:
path rendering quadratic path.
Comment: This is displayed correct with KSVG, the adobe plugin, inkscape, amaya (which has other nasty problems with cubic paths) and imagemagick. Gimp, sodipodi, gecko/librsvg have the same error as Opera.
Simple example for the second problem:
rendering of slopes of a cubic path.
A closed continuosly differentiable path is shown
(the circles are the control points). Therefore this
path does not contain any edges or corners, just
some slopes. The thin red line give the original path
(mainly visible with magnification),
for the same shape the stroke-width of the path is animated
for the blue one within 50s. After 50s the stroke-linejoin is
set from miter to round, after another 50s back to miter.
Both animations are repeated.
Because the path is continuosly differentiable and has no
corners and edges, the change of the stroke-linejoin cannot
have a visible effect on the presentation.
In general even if the path would be not continuosly differentiable
corners can only appear at the end points of the bezier curves, marked
with yellow circles. There is one exception for cubic paths - if a slope is
degenerated to a cusp, this is a not continuosly differentiable point and
therefore this is an edge or corner. But the path in this example does not
include any cusps.
Opera shows edges and corners instead of slopes.
Comment: The best rendering for this example is similar to a rounded end of the slope, with the adobe plugin and
sodipodi this looks already very good, for the given example I cannot recognise, if they render
the slope complete correctely or only as a round end.
Many others use something similar to a bevel and a few
use something like miter as Opera, which gives the worst result.
Reported to Opera as bug-186475.
Severity: Specification violation SVG-tiny and SMIL animation
Description: Opera 9tp1/2 and later builds, 8x have a wrong interpretation of the additivity of animation with just a 'to' attribute, Opera 8.x in general, Opera9tp1 just in combination with fill freeze for the higher priority to animation. For the correct behaviour SVG specification points to SMIL animation recommendation, giving a special default behaviour for such animation, which overwrites the additive attribute. Opera 8.x seems to use additive="replace" as default. This is wrong, for this special case additive="sum" is incorret, too, see recommendation. With Opera9tp1 fill freeze for the higher priority to animation does not freeze the complete values, looks like a freeze of a lower priority animation. Similar animations with animateTransform and animateMotion still completely wrong.
Simple animate example: two to animations. Test of the correct additive default behaviour of to animations.
