gecko/layout/reftests/svg/smil/anim-text-x-y-dx-dy-01.svg

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     class="reftest-wait"
     onload="setTimeAndSnapshot(5, true)">
  <title>Test animation of the &lt;length-list&gt; attributes on the 'text' element</title>
  <script xlink:href="smil-util.js" type="text/javascript"/>

  <style type="text/css">
    :root { font-size: 16px; }  /* see comment below - sets 1em == 16px */
  </style>

  <!-- If we start getting random orange on this test, see:
       https://bugzilla.mozilla.org/show_bug.cgi?id=515116#c34
    -->

  <!-- One of the things that this file tests is animation between lengths
       of _different unit_. One difficulty this creates is knowing the
       values to use in the reference file. For example, what length should
       be used in the reference to comparing against an animation that's mid
       way between 50px and 10in? The SMIL engine will convert the start
       length to the unit of the end length and then interpolate, but the
       number of inches in 50px is not always the same, so we can't fix how
       many inches is midway between 50px and 10in in the reference file. To
       get around this problem this test mainly pairs different units with a
       knows, fixed, relationship. For example, animating between cm and mm,
       or between 'in' and pt (72 pt/in) or between 'in' and pc (6 pc/in).
       Note that we can animate between px and em by fixing the relationship
       between these units by setting the CSS 'font-size' property to a fixed
       number of px units as we've done above.

       The problem with only testing pairs with a fixed relationship is that
       implementations may only implement interpolation between those pairs
       because it's easy. To test interpolation between pairs of units
       without a fixed relationship we use another strategy: we animate from
       zero of the start unit. Since zero is zero regardless of the unit, we
       then know what to use in the reference. In theory implementations might
       specialize for zero, but that's unlikely (hopefully!).

       (An alternative would be to only test end points of the animation, but
       implementations may use discrete animation rather than interpolation
       when lengths of different units are encountered, so that would be a bad
       approach.)

       (Another better alternative would be to use
       SVGLength.convertToSpecifiedUnits() in the reference file to figure out
       the conversion of the start unit and set values in the reference file
       dynamically.)
  -->

  <!-- Another thing that this file test is animation between lists
       of _different length_. One implementation strategy when faced with such
       an animation is to pad the shorter list with zeros for the purposes of
       animation. This works exactly as you would hope in the case of the
       <text> element's 'dx' and 'dy' attributes, since for those attributes
       lengths are offsets from the coordinate at which respective glyph's
       would otherwise be positioned. In other words, appending a list of
       zeros to any 'dx' or 'dy' attribute will never have an affect on
       rendering. However, in the case of 'x' and 'y' attributes on <text>,
       any lengths given are distances from zero along the relevant axis of
       the current coordinate system, and zero is not likely to be the
       position that all glyphs would otherwise be given. Their position will
       actually depend on CSS parameters, the implementation's text layout
       algorithm, and the layout of the characters that came before it. Hence
       zero padding any 'x' or 'y' attribute will likely drastically alter
       the rendering of the text, and in the case of animation would cause
       glyphs to animate from/to zero in their coordinate system instead of
       from/to their natural position. Clearly this is neither what authors
       would expect, or want, so Mozilla currently disallows animation of 'x'
       and 'y' if lists of different length are encountered to prevent content
       being created that relies on such undesirable behavior.

       Ideally the implementation would provide the SMIL engine with the
       natural position of each glyph so that it can animate from/to those
       positions. That's tricky, but we do have a bug open to try and
       implement that. See:

       https://bugzilla.mozilla.org/show_bug.cgi?id=573431
    -->

  <!-- Test calcMode="linear". -->

  <text transform="translate(20, 20)"
        x="10px 0.5cm 0.25in 0.5in 16px 0cm 0%">ABCDEFGH

    <!-- At 5s the animVal should be "20 10mm 3pc 72pt 2em 3% 1ex". -->
    <animate attributeName="x"
             calcMode="linear"
             begin="0s" dur="15s"
             to="40 20mm 6pc 144pt 4em 9% 3ex"
             fill="freeze"/>

    <!-- At 5s the animVal should be "20 10mm 3pc 36pt 2em 3% 1ex 1".
         Note that the 'to' list has one extra list item on purpose! -->
    <animate attributeName="dy"
             calcMode="linear"
             begin="0s" dur="15s"
             from="10px 0.5cm 0.25in 0.25in 16px 0cm 0%"
             to="40 20mm 6pc 72pt 4em 9% 3ex 3"
             fill="freeze"/>
  </text>


  <!-- Test 'by' animation. -->

  <text transform="translate(120, 20)"
        x="10px 0.5cm 0.25in 0.5in 16px 0cm 0%">IJKLMNOP

    <!-- At 5s the animVal should be "20 10mm 3pc 72pt 2em 3% 1ex". -->
    <animate attributeName="x"
             calcMode="linear"
             begin="0s" dur="15s"
             by="30 15mm 4.5pc 108pt 3em 9% 3ex"
             fill="freeze"/>

    <!-- At 5s the animVal should be "20 10mm 3pc 36pt 2em 3% 1ex".
         Note that the 'from' list is essentially zero length! -->
    <animate attributeName="dy"
             calcMode="linear"
             begin="0s" dur="15s"
             by="60 30mm 9pc 108pt 6em 9% 3ex"
             fill="freeze"/>
  </text>


  <!-- Test calcMode="paced". It doesn't make a lot of sense to use paced
       animation with a length list, but since we support it, we test it.
  -->

  <text transform="translate(220, 20)">QRSTUVWX

    <!-- At 5s the animVal should be "20 10mm 3pc 72pt 2em 3% 1ex". -->
    <animate attributeName="x"
             calcMode="paced"
             begin="0s" dur="15s"
             values="10px 0.5cm 0.25in 0.5in 16px 0cm 0%;
                     30 15mm 4.5pc 108pt 3em 6% 2ex;
                     40 20mm 6pc 144pt 4em 9% 3ex"
             fill="freeze"/>

    <!-- At 5s the animVal should be "20 10mm 3pc 36pt 2em 3% 1ex 1".
         Note that the 'to' lists have one extra list item on purpose! -->
    <animate attributeName="dy"
             calcMode="paced"
             begin="0s" dur="15s"
             values="10px 0.5cm 0.25in 0.25in 16px 0cm 0%;
                     30 15mm 4.5pc 54pt 3em 6% 2ex 2;
                     40 20mm 6pc 72pt 4em 9% 3ex 3"
             fill="freeze"/>
  </text>


  <!-- Test calcMode="discrete". In this case SMIL treats the 'from' and 'to'
       as two discrete values to jump between. Some authors may expect
       discrete animation to jump from integer to integer in the unit of the
       list item in question (or the unit of the 'to' item if the units of
       corresponding 'from' and 'to' items differ), but that's not the case.
  -->

  <text transform="translate(320, 20)">YZ123456

    <!-- At 5s the animVal should be "20 10mm 3pc 72pt 2em 3% 1ex". -->
    <animate attributeName="x"
             calcMode="discrete"
             begin="0s" dur="10s"
             from="10px 0.5cm 0.25in 0.5in 16px 0cm 0%"
             to="20 10mm 3pc 72pt 2em 3% 1ex"
             fill="freeze"/>

    <!-- At 5s the animVal should be "20 10mm 3pc 36pt 2em 3% 1ex".
         Note that the 'to' list has one extra list item on purpose! -->
    <animate attributeName="dy"
             calcMode="discrete"
             begin="0s" dur="10.1s"
             from="20 10mm 3pc 36pt 2em 3% 1ex"
             to="40px 2cm 1in 1in 16px 0cm 0% 3"
             fill="freeze"/>
  </text>

</svg>