Movatterモバイル変換

11.1Overview and Summary ofChanges for SMIL 3.0

This section is informative.

The SMIL 3.0 specification leaves the SMIL 2.1 Transition Effects Module[SMIL21-transition] mostly unchanged. The only changes are that severaltypos and some examples have been corrected and some clarifications wereadded.

11.2 Introduction

This section is informative.

In most public descriptions of SMIL, the language is described as"allowing authors to bring TV-like content to the Web." One aspect ofpresentations commonly seen on television are transitions such as fades andwipes. The purpose of this section is to specify the semantics and syntax fordescribing transitions within SMIL and other XML-based documents. Also, thisspecification describes a taxonomy of transitions based on SMPTE 258M-1993[SMPTE-EDL] as well as a compact set of parameters which be used to expressthis set of transitions.

Consider a simple still imageslideshow of four images, each displayed for 5 seconds. Using SMIL Timing,this slideshow might look like the following:

...<seq>    <img src="butterfly.jpg" dur="5s" ... />    <img src="eagle.jpg"     dur="5s" ... />    <img src="wolf.jpg"      dur="5s" ... />    <img src="seal.jpg"      dur="5s" ... /></seq>...

Currently when this presentation plays, we see a straight "cut" from oneimage to another, as shown inthis animatedimage. However, what we would like to see are three left-to-right wipesin between the four images: in between butterfly.jpg and eagle.jpg at 5seconds, in between eagle.jpg and wolf.jpg at 10 seconds, and in betweenwolf.jpg and seal.jpg at 15 seconds. This is illustrated bythis animated image. Thepurpose of this document is to define the syntax and semantics of specifyingtransitions such as these in XML-based documents.

Although the transitions described in this document arevisualtransitions, the concepts apply toaudio transitions as well byfocusing on the overlap of the audio media in time rather than overlap in thelayout. However, this document does not define any audio transition effectsor specifically address how audio transitions should behave.

11.3 Module Overview

This section is normative.

SMIL 3.0 Transition functionality is partitioned across the following 4modules:

BasicTransitions Module defines a style-like shorthand method of specifying transitions.
FullScreen Transitions Module defines mechanisms for transitions that effect the entire screen.
InlineTransitions Module enables a much finer level of control over transitions.
TransitionModifiers Module provides additional control over the visual appearance of a transition.

11.4Transition Model

This section is informative.

Transitions are modeled as animated filter behaviors. When a transitionmodule is included in a language profile, all elements with renderablecontent implicitly have thetransition filter behavior added to them.By default the behavior has no effect, but attributes and elements areprovided to specify and control the effect of the transition behavior on therenderable content. Renderable content is declared in theSMIL Media Object Modules using mediaelements. Other languages, such as HTML, provide additional elements such asthe span and div for rendering. In this document the terms "media element"and "media object" include all "renderable content", defined by the hostlanguage.

The transition filter behavior uses the background as one input. In thiscontext, the background is whatever is currently present in the layout wherethe transition will be applied. Therefore, the background might includeactively changing media, frozen media, or solid background colors. It alsotakes as input the media object to which the transition will be applied. Themedia object may be used as either the source or the destination input, withthe background supplying the other input. The media object also defines thearea in which the transition will occur. Certain transitions, such as fade-infrom a solid color, will only take one input - the media object to which thetransition is applied.

In case a SMIL language profile supportsFullScreenTransitions module thearea to which the transition applies may be different and, hence, the effectperceived by the viewer is of multiple media items transitioning. However,all timing rules and other rules for applying transitions still treat thetransition exactly the same as when applying it to a single media item.

A free parameter common to all transition filter behaviors is theprogress through the simple duration of the transition effect, whichis abstractly considered to be the progress through the filter effect. Weestablish the convention that progress is a real number in the range 0.0-1.0,where a progress of 0.0 implies that the output of the filter is completelythe background and where a progress of 1.0 implies the output of the filteris completely the destination media. Values in between result in anapplication of the transition filter behavior that combines the backgroundand destination media in some manner. All other parameters of the transitionare assumed to be part of the filter effect itself.Progress is the only parameter which is animated.Other parameters are used to specify the filter effect, but are notanimated.

The distinction between animating only the progress of the filter versusanimating one or more properties of the media is illustrated by thefollowing. In the left-to-right wipe in theIntroductory example, wecould either think of this transition as:

A filter which clips the destination media. The left side of the clipping rectangle would always be coincident with the left side of the destination media and the right side of the clipping rectangle would vary. Therefore, this transition could be thought of as animating the right side of the clipping rectangle.
A filter which is predefined to be a left-to-right wipe whose progress varies in the range 0.0-1.0. When progress is 0.0, the background is shown. When progress is 0.5, the left half of the destination media is shown and the right half of the background is shown. When progress is 1.0, all of the destination media is shown.

This may seem to be a very minor distinction for a left-to-right wipe, butthen think of the corresponding distinction for a cross-fade. We could thinkof a cross-fade transition as:

Animation of an "opacity" property of both the destination media and the background; or
Animation of progress in a filter which knows that a progress of 0.5 means a 50% blend, a progress of 0.75 means 75% of the destination media and 25% of the background, etc.

In some cases, it may seem convenient to think of animating a particularproperty unique to each type of transition. However, that model does notgeneralize well across the broad variety of transitions currently in usetoday. Therefore, in order to maintain simplicity of this model, we think ofboth the left-to-right wipe and the cross-fade as "black boxes" which bothtake the same inputs - the background, destination media, and the progressvalue.

XML elements and attributes are provided to control the properties of thetransition. However, the transitions themselves are not a property of theattribute or elements used to control the transition behavior. In the model,the transitions are a behavioral property of the media element itself.

Transitions are hints to thepresentation. Implementations must be able to ignore transitions ifthey so desire and still play the media of the presentation. This isequivalent to saying that the transition filter behavior does not execute, orhas no effect. Transitions do not alter the active duration of the mediaelements that are involved in the transition. The transition behaviorsoperate within the active duration of their respective media elements. Thebehavior of multiple simultaneous transitions active on an element at a timeis undefined.

We will introduce two methods of specifying transitions:

"Style-like" transition shorthand. In this case, the author defines a set of transitionclasses and then sets the transition filter behavior to one of these classes by using attributes on the media elements. The same transition class may be applied several times to different media via thetransIn andtransOut attributes as specified in theBasicTransitions module. Additionally, each of the transitions plays in a default manner; that is, the progress runs linearly from 0.0-1.0 over the specified transition duration.
Inline transitions. In this case, the author has full control over the progress of a transition. The progress may be accelerated, decelerated, animated forward, animated backwards, etc. These transitions are applied with atransitionFilter element as described in theInlineTransitions module. Inline transitions are based on the animation framework in theBasicAnimation module and allow the progress of a media element's transition behavior to be explicitly controlled, much like theanimateMotion element allows the spatial location of a media object to be directly manipulated.

11.5Transition Taxonomy

This section is normative.

We will classify transitions according to a two-level taxonomy of typesand subtypes. Each of the transition types describe a group of transitionswhich are closely related. Within that type, each of the individualtransitions are assigned a subtype which emphasizes the distinguishingcharacteristic of that transition. Usually, that distinguishingcharacteristic has something to do with the origin or direction of thegeometric pattern of that transition. For instance, one of the transitiontypes is called "barWipe" and represents SMPTE Wipe Codes 1 and 2. SMPTE WipeCode 1 is a wipe consisting of a vertical bar moving left to right. SMPTEWipe Code 2 is a horizontal bar moving top to bottom. Therefore, the subtypefor SMPTE Wipe Code 1 is called "leftToRight" and the subtype for SMPTE WipeCode 2 is called "topToBottom".

Since the table of transition types and subtypes is quite extensive, wewill not present the exhaustive list here. For the complete list of thepredefined transition types and subtypes, as well as their mapping to SMPTEWipe Codes, see theAppendix. Notethat the mapping to SMPTE Wipe Codes are provided for reference only.

11.5.1 Default Transition Subtypes

For each of the types, one of the subtypes is labeled as the "default"subtype in theAppendix. If thistransition class is not available or not implemented by the user agent, thenthe user agent should fall back on the default subtype for that transitionfamily. This allows authors to specify a type for a transition class withoutrequiring that they specify a subtype for the transition class. For moredetail on parsing rules and fallback semantics, see theTransition Parsing Rules section.

11.5.2 Required Transitions

Implementations are required to implement the default subtype for each ofthe following transition types.

Transition type	Default Transition subtype	SMPTE Wipe Code
barWipe	leftToRight	1
irisWipe	rectangle	101
clockWipe	clockwiseTwelve	201
snakeWipe	topLeftHorizontal	301

Implementation of the rest of the transition types and subtypes listed intheAppendix is encouraged, but notrequired due to the large number of transitions.

11.6BasicTransitions Module

This section is normative.

Now that a taxonomy of transition types and subtypes is defined, we nowdiscuss a "style-like" shorthand syntax for transitions. This shorthandsyntax requires specification of the following:

Theclass of transition to be applied. For instance, to use a 1-second left-to-right wipe in a presentation, the wipe is defined as a transition class defined with thetransition element.
Themedia elements to which this transition class is applied. In this shorthand syntax, the transition class is applied to the media element with thetransIn andtransOut attributes.

11.6.1The transition element

Thetransition element definesa single transition class. This element may appear in different places in thedocument, depending upon the language profile. However in most cases, thetransition element will beallowed only in thehead of thedocument. For clarity, a grouping "container" element (such as thelayoutelement in SMIL) may be desired inorder to group all of thetransition elements together. Sincethere may be multiple transition classes used in a document, then there maybe multipletransition elementsin thehead of the document.

Element attributes

type: This is the type or family of transition. This attribute is required and must be one of the transition families listed in theTaxonomy section (or it must be an extended transition type provided by the user agent). See theTransition Parsing Rules for an algorithm to determine which transition to use.
subtype: This is the subtype of the transition. This parameter is optional and if specified, must be one of the transition subtypes appropriate for the specified type as listed in theAppendix (or it must be an extended transition subtype provided by the user agent). If this parameter is not specified then the transition reverts to the default subtype for the specified transition type. See theTransition Parsing Rules for an algorithm to determine which transition to use.
dur: This is the duration of the transition. The value of this attribute must be aclock-value as defined by theSMIL Timing and Synchronization Module. The default duration is the intrinsic duration built into the transition. All of the transitions defined in theAppendix have a default duration of 1 second.
startProgress: This is the amount of progress through the transition at which to begin execution. Legal values are real numbers in the range 0.0-1.0. For instance, we may want to begin a crossfade with the destination image being already 30% faded in. For this case, startProgress would be 0.3.
The default value is 0.0.
endProgress: This is the amount of progress through the transition at which to end execution. Legal values are real numbers in the range 0.0-1.0 and the value of this attribute must be greater than or equal to the value of thestartProgress attribute. If endProgress is equal to startProgress, then the transition remains at a fixed progress for the duration of the transition.
The default value is 1.0.
direction: This specifies the direction the transition will run. The legal values are "forward" and "reverse". The default value is "forward". Note that this does not impact the media being transitioned to, but only affects the geometry of the transition. For instance, if you specified a type of "barWipe" and a subtype of "leftToRight", then the media would be wiped in by a vertical bar moving left to right. However, if you specified direction="reverse", then it would be wiped in by the same vertical bar moving right to left. Another example is the type of "starWipe" and subtype of "fourPoint". For this transition, running the transition forward reveals the destination media on the inside of a four-point star which starts small and gets larger as the transition progresses. Running this transition in reverse would reveal the destination media in the area outside of a large four-point star. The star begins large and gets smaller as the transition progresses. Note that not all transitions will have meaningful reverse interpretations. For instance, a crossfade is not a geometric transition, and therefore has no interpretation of reverse direction. Transitions which do not have a reverse interpretation should ignore the direction attribute and assume the default value of "forward".
fadeColor: If the value of the "type" attribute is "fade" and the value of the "subtype" attribute is "fadeToColor" or "fadeFromColor", then this attribute specifies the starting or ending color of the fade. If the value of the "type" attribute is not "fade", or the value of the "subtype" attribute is not "fadeToColor" or "fadeFromColor", then this attribute is ignored. Legal color values are CSS2 color values[CSS2-color-values].
The default value is "black".

Element content

Thetransition element mayhave theparam element as a child.

Examples of thetransition element

This section is informative.

For example, suppose we wanted to define two transition classes: a simple2-second fade-to-black and a 5-second keyhole-shaped iris wipe. Thesetransition classes may be expressed as:

    ...    <transition xml:id="ftb2" type="fade" subtype="fadeToColor"                dur="2s" fadeColor="#000000" />    <transition xml:id="star5" type="starWipe" subtype="fivePoint"                dur="5s" />    ...

11.6.2 The param element

This section is normative.

The set of parameters discussed above are adequate for expressing all thetransitions defined in this document. However, an implementation may chooseto extend the set of transitions and define their own transition types andsubtypes. Some of these new transition classes may need parameters which arenot covered by the current set of attributes listed above. The purpose of theparam element is to provide a genericmeans of supplying parameters to these extended transition types andsubtypes.

The transition element may take theparam element, defined in theSMIL MediaParamModule, as a child element. This element may be included from HTML orfrom some other module, depending upon the profile of the host language.

This section is informative.

For instance, suppose an implementation decided to create a new transitiontype called "superCool" and a subtype called "fire". This new transitionneeds a parameter called "flameLength". The example below shows how thisimplementation could use the param element to provide a value for"flameLength".

<transition xml:id="myfire" type="superCool" subtype="fire">    <param name="flameLength" value="20" /></transition>

Note that the meaning of the additional parameters provided to thetransition element depends upon the implementation of the specifictransition.

11.6.3ThetransIn andtransOut attributes

This section is normative.

Once a transition class has been defined in the head of a document, then atransition instance may be created by applying the transition class to theactive duration of a media object element or other element with "renderablecontent". We do this by specifying atransIn ortransOut attribute on the media objectelement. Transitions specified with atransIn attribute will begin at thebeginning of the media element's active duration. Transitions specified withatransOut attribute will end atthe end of the media element's active duration or end at the end of theelement's fill state if a non-default fill value is applied.

ThetransIn andtransOut attributes are added to allmedia object elements listed in theSMIL Media Object Module. Thedefault value of both attributes is an empty string, which indicates that notransition should be performed.

The value of these attributes is a semicolon-separated list of transitionid's. Each of the id's should correspond to the value of the XML identifierof one of thetransition elementspreviously defined in the document. The purpose of the semicolon-separatedlist is to allow authors to specify a set of fallback transitions if thepreferred transition is not available. The first transition in the listshould be performed if the user-agent has implemented this transition. Ifthis transition is not available, then the second transition in the listshould be performed, and so on. If the value of thetransIn ortransOut attribute does not correspond tothe value of the XML identifier of any one of thetransition elements previously defined,then this is an error. In the case of this error, the value of the attributeshould be considered to be the empty string and therefore no transitionshould be performed. For more detailed parsing rules, see theTransition Parsing Rules section.

Rules For Applying Transitions to Media Elements

This section is informative.

Since the purpose of transitions is to pass from one media object to another, then transitions are applied so that they either begin or end (or both) with some media object.
However, the visual effect may appear to be applying this transition in the middle of an element's active duration. Consider the following example:
```
    ...    <par>        <img src="butterfly.jpg" dur="10s" />        <img src="eagle.jpg" begin="3s" dur="4s" />    </par>    ...
```
Assuming that eagle.jpg is z-ordered on top of butterfly.jpg, then transitions applied to both the beginning and end of eagle.jpg would have the visual appearance of being applied during the active duration of butterfly.jpg. However, from the authoring perspective, they are still applied at the beginning and end of eagle.jpg.
Transitions happen by default during the active duration plus any fill period of the element to which they are applied. See the next rule for the effect of the fill value on the begin time of an out transition (transOut). Applying a transition to an element does not affect duration of the element. For instance, in the example below, applying a 1-second transition at the beginning of eagle.jpg does not add or subtract from the active duration of eagle.jpg - it is still displayed from 5-10 seconds in the presentation. Applying a 1-second transition at the beginning of eagle.jpg makes the transition take place from 5-6 seconds and applying a 2-second transition at the end of eagle.jpg would make the transition happen from 8-10 seconds.
```
...<seq>    <img src="butterfly.jpg" dur="5s" ... />    <img src="eagle.jpg"     dur="5s" ... /></seq>...
```
Out transitions (transOut) end at the end of the active duration of an element plus any fill period. For elements with the default fill behavior of remove, out transitions end at the end of the active duration of the element. For elements with other values of fill, the transition ends at the end of the frozen period of the element.
For instance, in the following presentation the fill behavior of the image element is "freeze", which keeps the image frozen until its parent ends. The parent ends when all of its children end, which is the end of the video at 30 seconds. In order to end at the end of the frozen duration (30 seconds) the fade-to-black transition begins at 29 seconds. Therefore both elements fade to black together at 29 seconds.
```
    ...    <transition xml:id="toblack1s" type="fade" subtype="fadeToColor"                   fadeColor="#000000" dur="1s"/>    ...    <par>        <img   ... dur="10s" transOut="toblack1s" fill="freeze"/>        <video ... dur="30s" transOut="toblack1s"/>    </par>
```
However, in the following example the fill behavior of the image element is "remove". Therefore, the transition ends at the end of the active duration of the element. The image element fades to black starting at 9 seconds and the video element fades to black starting at 29 seconds.
```
    ...    <transition xml:id="toblack1s"   type="fade" subtype="fadeToColor"                   fadeColor="#000000" dur="1s"/>    ...    <par>        <img   ... dur="10s" transOut="toblack1s" fill="remove"/>        <video ... dur="30s" transOut="toblack1s"/>    </par>
```
The active duration for the media element to be transitionedto (the destination media) should either overlap the active duration or the fill state for the media element to be transitionedfrom (the background). In theIntroductory example, the active duration for each destination media object immediately follows the end of the active duration of each background media object. In these cases (where the active durations immediately follow but do not overlap), the fill="transition" value should be used to enable the transition between the frozen last frame of the previous (background) media and active frames of the current (destination) media. Seefill="transition" for more information. In cases where the active durations overlap (and hence the media being played to have different z-orders), the transition is between active frames of both media.
In the following example the active durations do not overlap but the fill="transition" freezes the last frame of the first video. The result is a crossfade between the last frame of foo1.mpg and active frames of foo2.mpg.
```
    ...    <seq>        <video src="foo1.mpg" fill="transition"... />        <video src="foo2.mpg" transIn="xfade1s" ... />    </seq>    ...
```
In the following presentation, however, the crossfades both at the beginning and end of foo2.mpg are between active frames of both foo1.mpg and foo2.mpg since their active durations overlap. The example assumes the videos are at different z-orders.
```
    ...    <transition xml:id="xfade" type="fade" subtype="crossfade" dur="1s" />    ...    <par>        <video src="foo1.mpg" dur="30s" />        <video src="foo2.mpg" begin="10s" dur="10s"               transIn="xfade" transOut="xfade" />    </par>    ...
```
If the active durations for the media objects involved in the transition do not overlap, then the background for the area behind the media should be used. For example, the active durations for img1.jpg and img2.jpg do not overlap in the following example. Therefore, img1.jpg will transition to whatever is behind it.
```
    ...    <transition xml:id="awipe" type="barWipe" dur="1s" ... />    ...    <par>        <img src="img1.jpg" dur="2s" transOut="awipe" .../>        <img src="img2.jpg" begin="5s" dur="2s"       .../>    </par>    ...
```
If both an in and out transition are specified on a media element, and the times for those transitions overlap, then the in transition takes precedence, and the out transition should be ignored and no out transition should be performed.
For instance, in the following example, the "barWipe" in transition will take precedence over the "fadeToColor" out transition. The in transition will fully take place for the first 2 seconds of img1.jpg, and the out transition is ignored and no out transition is performed.
```
    ...    <transition xml:id="awipe"   type="barWipe"    dur="2s" ... />    <transition xml:id="toblack" type="fadeToColor dur="2s" ... />    ...    <img src="img1.jpg" dur="3s" transIn="awipe" transOut="toblack" .../>    ...
```
Since transitions imply passing from the beginning or end of display of one media to another, transitions do not repeat.
Consider the following example. The img2.jpg has a simple duration of 5 seconds, but an active duration of 15 seconds, since it plays a total of three times. However, the in transition only plays once at the beginning of the active duration of img2.jpg, which is at 5 seconds into the active duration of the sequence time container. The out transition also plays only once, starting at 19 seconds into the active duration of the sequence time container.
```
    ...    <transition xml:id="awipe"   type="barWipe"     dur="1s" ... />    <transition xml:id="toblack" type="fadeToColor" dur="1s" ... />    ...    <seq>        <img src="img1.jpg" dur="5s" fill="transition" .../>        <img src="img2.jpg" dur="5s" repeatCount="3"             transIn="awipe" transOut="toblack" ... />        <img src="img3.jpg" dur="5s" .../>    </seq>    ...
```

Use of fill="transition"

Thefill attribute, defined in theSMIL Timing and Synchronization Modules,allows an author to specify that an element should be extended beyond itsactive duration byfreezing the final state of the element. A newfill value,"transition", is required to enable transitions betweenelements that would not normally be displayed at the same time. This fillattribute value may be applied only to elements with renderable content andis not applicable to pure time container elements such aspar,seq,andexcl. Iffill="transition"is applied to a pure time container element, then the value is ignored andreverts to its default value.

Thefill="transition" value indicates that after its activeduration ends the element will be frozen and it will remain frozen until theend of the next transition on an element with which it overlaps in thelayout. The element containing thefill="transition"will be removed when the transition ends. The timing rules defined in theSMIL Timing and Synchronization Modules stillapply: the element is subject to the constraints of its parent time containerand may be removed by its parent regardless of whether or not a transition isdeclared. Each profile should define the meaning of overlapping in thelayout.

In the following examplenot using transitions, the defaultbehavior is to remove the object representing img1.jpg after 10 seconds.

    ...    <seq>        <img src="img1.jpg" dur="10s" ... />        <img src="img2.jpg" dur="10s" ... />    </seq>    ...

Adding a transition between img1.jpg and img2.jpg requires that img1.jpgremains displayed after its active duration ends so that it may be used bythe transition to img2.jpg. The first image is removed as soon as thetransition ends. Thefill="transition" enables this behavior as illustrated bythe following example.

    ...    <transition xml:id="awipe" type="barWipe" dur="1s" ... />    ...    <seq>        <img src="img1.jpg" dur="10s" fill="transition" ... />        <img src="img2.jpg" dur="10s" transIn="awipe"   ... />    </seq>    ...

Slideshow example with transitions

After adding thefill andtransIn attributes, our example slideshowfrom the Introduction section now looks like the following:

...<transition xml:id="wipe1" type="barWipe" subtype="leftToRight" dur="1s"/>...<seq>    <img src="butterfly.jpg" dur="5s" fill="transition" ... />    <img src="eagle.jpg"     dur="5s" fill="transition" transIn="wipe1" ... />    <img src="wolf.jpg"      dur="5s" fill="transition" transIn="wipe1" ... />    <img src="seal.jpg"      dur="5s"                   transIn="wipe1" ... /></seq>

Now the presentation plays as follows, as illustrated bythis animated image.

At 0 seconds, cuts directly to butterfly.jpg.
At 5 seconds begins a 1-second left-to-right wipe from butterfly.jpg to eagle.jpg.
At 6 seconds, eagle.jpg is fully displayed and remains displayed for 4 more seconds until 10 seconds.
At 10 seconds, begins a 1-second left-to-right wipe from eagle.jpg to wolf.jpg.
At 11 seconds, wolf.jpg is fully displayed for 4 more seconds until 15 seconds.
At 15 seconds, begins a 1-second left-to-right wipe to from wolf.jpg to seal.jpg.
At 16 seconds, seal.jpg is fully displayed for 4 more seconds until 20 seconds.
At 20 seconds the presentation ends.

Notice that these transitions occurduring the active duration ofeach of the images which reference the transition and do not add or subtractfrom their host element's active duration. In this case, the transitionoccurs at the beginning of each media element's active duration.

Notice the importance offill="transition". If we had not specifiedfill="transition"on butterfly.jpg, eagle.jpg, and wolf.jpg, then the transitions at 5, 10, and15 seconds would have taken place between the background of the playback area(or the default background color, depending on how the layout language isspecified) instead of the previous image in the sequence.

Exclusive children and fill="transition"

Thefill="transition" also enables transitions from one exclchild to another when the previously active child would normally be removedfrom the display. In the following example the first image transitions infrom the background, displays for 5 seconds and then freezes because of thefill="transition". The next child activated by a buttonclick will transition in from butterfly.jpg. When that child completes itwill also freeze due to thefill="transition", remaining available for use in the nexttransition. It will transition in to the next image activated by a buttonclick, and so on.

...<transition xml:id="wipe1" type="barWipe" subtype="leftToRight" dur="1s"/>...<excl>    <img src="butterfly.jpg" begin="0" dur="5s" fill="transition" transIn="wipe1" ... />    <img src="eagle.jpg"     begin="button1.click" dur="5s" fill="transition" transIn="wipe1" ... />    <img src="wolf.jpg"      begin="button2.click" dur="5s" fill="transition" transIn="wipe1" ... />    <img src="seal.jpg"      begin="button3.click" dur="5s" fill="transition" transIn="wipe1" ... /></excl>

Note that fill takes effect after the active duration of an element ends.In the above example, if button2 is clicked at 3 seconds, then butterfly.jpgwill end, and thefill="transition" value for butterfly.jpg will be in effectthrough the end of the next transition. Therefore the transition will occurfrom butterfly.jpg to wolf.jpg and the frozen butterfly.jpg will disappearwhen the transition completes.

The pauseDisplay attribute of the priorityClass element, defined in theSMIL Timing and Synchronization Modules may alsobe used to control the display of children of an exclusive element. In theexample above, pauseDisplay could be used to keep butterfly.jpg displayedwhen paused so the transition would occur between butterfly.jpg to the nextmedia activated, and butterfly.jpg would continue to be displayed after thetransition (assuming that it is not completely covered by the othermedia).

11.6.4 Handling Parameter Errors

This section is normative.

Transitions parameters may be specified incorrectly in many different wayswith varying levels of severity. Therefore, the following errors should behandled with the specified action:

Transition type is not valid. If the implementation does not recognize the value of the type attribute, or if that transition type is not implemented, then this transition class is invalid. However, this does not necessarily mean that no transition will be performed, as specified in theTransition Parsing Rules section.
Transitions subtype is not valid for specified transition type. The specified transition subtype should be ignored and the default subtype for the specified transition type should be performed.
Transition duration is not specified. The default duration of 1 second should be assumed.
Transition parameter besides type or subtype is outside the legal range. If a transition parameter is specified outside of the legal range, then the default value of the parameter should be assumed.
Transition parameter does not apply to this transition type. Since not all transition parameters apply to all transition types, then a common error could be to specify a transition parameter which does not apply to the specified transition type. These irrelevant parameters should be ignored. For instance, the "borderWidth" parameter does not apply to the "fade" transition type. If "borderWidth" were to be specified for the "fade" transition type, then it should be ignored.
Transition duration is longer than the duration of the media object itself. In this case, the entire transition should be ignored and not performed.

11.6.5Transition Parsing Rules

This section is normative.

As stated earlier, eachtransition may have a defaulttransition subtype. Also, thetransIn ortransOut attributes on media elementstake a semicolon-separated list of transition id's to indicate a list offallback transitions. To eliminate ambiguity between the default subtype andthe fallback list, this section defines an algorithm that must be followed todetermine the transition to perform. The general procedure is that the firstresolved transition from the list of fallback transitions is the one thatshould be performed.

Given one or more previously declaredtransition elements and a list offallback transition id's (specified on thetransIn ortransOut attributes), an implementationmust use the following algorithm to determine the transition to perform.

Setcurrent-id to the first id in the list.
Ifcurrent-id is empty (we have no more id's in the list), then exit this algorithm. The implementation must not consider this an error and must not perform any transition.
Ifcurrent-id is the id of some previously definedtransition element then go to Step 4. If not, then setcurrent-id to the next id in the list and go to Step 2.
If the value of the "type" attribute on thetransition element identified bycurrent-id is known to the implementation then go to Step 5. If not, then setcurrent-id to the next id in the list and go to Step 2.
If the "subtype" attribute is specified on thetransition element identified bycurrent-id then go to Step 6. If it is not specified, then the implementation must exit this algorithm and perform thedefault transition subtype for the specified transition type.
If the value of the "subtype" attribute on thetransition element identified bycurrent-id is known to the implementation then the implementation must exit this algorithm and perform the transition specified by the type and subtype. If it is not, then setcurrent-id to the next id in the list and go to Step 2.

11.6.6Audio Transitions

This section is normative.

Audio transitions animate the audio component of the target media object.SMIL specifies two audio transitions, "audioFade" and "audioVisualFade". Theyboth adjust the audio volume of the target media. The latter one alsoanimates the visual component of the media.

The "audioFade" transition fades an audio clip in or out by linearlyadjusting the volume of the clip. As with the visual "fade" transition thedirection of the transition depends on whether it is used intransIn ortransOut attribute. To achieve cross-fadeeffect between two audio clips, the clips must overlap in time and the"audioFade" transitions may be applied simultaneously to both.

The "audioVisualFade" fade acts like a combination of the "audioFade" andthe visual "fade" transitions. It has the same subtypes as "fade" transition.Future versions of the specification may provide a general mechanism forcombining transitions.

Since thefill attribute semanticsdictate that audio is silent during the fill period, thefill valuefill="transition"can't be used for transition effects between audio clips. To mix audio clipsusing transition effects the timeline of the clips must overlap.

This section is informative.

Example:

The following example cross-fades between two audio clips. For cross-fadeeffect the clips must overlap in the presentation timeline. Since audio clipsare not audible during the fill period, a sequence time container would notbe suitable for achieving this effect.

<transition xml:id="four_sec_fade" type="audioFade" subType=fade" dur="4s"/>. . .<par>  <audio xml:id="audio1" ... transOut="four_sec_fade" />  <audio xml:id="audio2" ... begin="audio1.end-4s" transIn="four_sec_fade" /></par>

11.6.7FullScreen TransitionsModule

This section is normative.

The FullScreenTransitions module adds a single attribute to thetransition element:

Element attributes

Thetransition element isextended with the following attribute:

scope

This attribute designates the destination area of the transition. The allowable values are

region: In this case the transition behaves as specified in theBasicTransitions module. This is the default value.
screen: In this case the destination area encompasses a larger area, as defined in the language profile.

The media items that transition together with the master media item areall those media items that are rendering within the area defined by the scopeattribute at the time the transition starts. Therefore, atransIn transition effect transitions fromthe set of media items defined as "background" in theTransition Model to the set of mediaitems that would have been visible at the start time if notransIn attribute had been present. AtransOut transition is from a setof media items visible at the start time of the transition to the set ofmedia items that should be visible just after the master media item finishes(note that this set does not depend on whether transOut is specified ornot).

Media items that start or end during the transition are treated in thesame way as the background media items (see theBasicTransitions module).

This section is informative.

Using these definitions a full-screen transition may be added to aboveexample as follows:

...<head>   <transition xml:id="diagonalWipeFullScreenTransition" type="clockWipe" subtype="clockwiseTwelve"                dur="1s" scope="screen" />  ...</head><body>  <par dur="10s">        <img  xml:id="left1"   src="left1.jpg"  region="leftpane"  dur="7s" fill="transition"  />        <text xml:id="right1"  src="right1.txt" region="rightpane" dur="7s" fill="transition"  />        <img  xml:id="left2"   src="left2.jpg"  region="leftpane"  begin="7s" dur="7s" />        <text xml:id="right2"  src="right2.txt" region="rightpane" begin="7s" dur="7s"                            transIn="diagonalWipeFullScreenTransition" />  </par></body>...

11.6.8Extending The Set OfTransitions

This section is normative.

In the algorithm specified earlier for determining which transition toperform, there is an implicit method for extending the set of transitions. Ifthe new transition does not fall into any of the general descriptions oftransition families in theTransitionTaxonomy section, implementations may create a new transition type (a newfamily of transitions) and then create new transition subtypes under thatnewly-defined type. However, it is recommended that if the new transitionfalls into one of the existing families of transitions, implementationsshould simply extend the set of subtypes for that existing type.Implementations may use whatever type and subtype names they choose for theseextended transitions. However, when these new transitions are used within adocument, they must be namespace-qualified.

11.7InlineTransitions Module

This section is informative.

As mentioned in theTransitionModel section, SMIL 3.0 Transitions allow two methods of specifyingtransitions: a shorthand method and an inline method. TheBasicTransitions module specifies theshorthand method while this module specifies the inline method. Inlinetransitions provide additional timing and progress control compared to theshorthand transitions. The transitionFilter element provides the inlinetransition support.

11.7.1 ThetransitionFilter element

This section is normative.

ThetransitionFilterelement is an animation element, similar to the animateMotion element definedin theSMIL 3.0 BasicAnimation Module. TheanimateMotion element animates the position of an element. In contrast, thetransitionFilter element animates the progress of a filter behavior(transition) on a media element or elements with renderable content. Thefilter behavior temporarily alters the visual or aural rendering of themedia. The transitionFilter element may target any element with "renderablecontent", not necessarily a media element. The host language determines whichelements to which transitionFilter may be applied. For instance, in HTML, aspan or a div may represent "renderable content". The transitionFilterelement may target a renderable content element in two ways: it may be thechild of that element, or with the targetElement attribute.

The transitionFilter element shares many of the attributes from thetransition element. It integratestiming support from the SMIL 3.0 BasicInlineTiming Module, and animationsupport from the SMIL 3.0 BasicAnimation module. This module may also becombined with other SMIL 3.0 Modules such as TimeManipulations, depending onthe modules implemented by the host language.

A transitionFilter element may define the target element of the transitioneither explicitly or implicitly. An explicit definition uses an attribute tospecify the target element. The syntax for this is described below.
If no explicit target is specified, the implicit target element is the parentelement of the transitionFilter element in the document tree. It is expectedthat the common case will be that a transitionFilter element is declared as achild of the element to be animated. In this case, no explicit target need bespecified.
This element must target a media element or other element with renderablecontent, as defined by the host language. This is in contrast toBasicTransitions that are declared in the "transition" element and thenspecified in thetransIn ortransOut attributes that are applied tomedia elements.
When an implicit targetElement reference is used, the transitionFilterelement must be a child of an element that supports transition effects (or ithas no effect).

Similar to howtransIn andtransOut areattributes of the media object to which thetransition is applied, the transitionFilter element is achild of the media object to which thetransition is applied. However, even though the transitionFilter element is achild of a media object, it is not a time container, and may not extend theactive duration of the media object. Therefore, if transitionFilter is achild of a media element, it may only apply a transition to that mediaelement during that media element's active duration. If it is desired toapply a transition during an element's frozen period, then transitionFiltershould not be a child of the media element. Rather, the targetElementattribute should be used to target that media element.

Note that the transitionFilter element represents an "in" transition inthe sense that the destination media (the media that is fully visible whenprogress is 1.0) is the media to which the transition is applied (the parentmedia, in this case). However, since transitionFilter gives full control overthe timing of the progress, an "in" transition may be made to look like an"out" transition by simply running the transition from a progress of 1.0 andending the transition at a progress of 0.0.

transitionFilter Element attributes

type

This is the same attribute as in thetransition element.

subtype

This is the same attribute as in thetransition element.

mode

Indicates whether the transitionFilter's parent element will transition in or out. Legal values are "in" indicating that the parent media will become more visible as the transition progress increases and "out" indicating that the parent media will become less visible as the transition progress increases. The default value is "in". Unlike thetransIn andtransOut attributes on media elements, the mode attribute does not automatically tie the transitionFilter to the begin or end of the media. Authors may use the begin attribute on the transitionFilter to indicate the begin time for the transitionFilter.

fadeColor

This is the same attribute as in thetransition element.

begin

Defined in theSMIL Timing and Synchronization Module. This attribute is optional and the default is 0 seconds.

dur

Defined in theSMIL Timing and Synchronization Module. The default duration is the intrinsic duration built into the transition. All of the transitions defined in theAppendix have a default duration of 1 second.

end

Defined in theSMIL Timing and Synchronization Module.

repeatCount

Defined in theSMIL Timing and Synchronization Module.

repeatDur

Defined in theSMIL Timing and Synchronization Module.

from

Amount of progress through the transitionFilter from which to begin execution of the transitionFilter. Legal values are real numbers in the range 0.0-1.0. For instance, this attribute would equal "0.3" to begin a cross-fade with the destination image faded in by 30%. This attribute is defined in theSMIL 3.0 BasicAnimation Module and is similar to the startProgress attribute on the transition element. The default value is 0.0. Ignored if the values attribute is specified.

to

Amount of progress through the transitionFilter at which to end execution of the transitionFilter. Legal values are real numbers in the range 0.0-1.0. This attribute is defined in theSMIL 3.0 BasicAnimation Module and is similar to the endProgress attribute on the transition element. The default value is 1.0. Ignored if the values attribute is specified.

by

Specifies a relative offset value for the progress of the transitionFilter. Legal values are real numbers in the range 0.0-1.0. Defined in theSMIL 3.0 BasicAnimation Module. Ignored if the values attribute is specified.

values

A semicolon-separated list of one or more values specifying the progress of the transitionFilter. This attribute may provide more precise control over the progress than a combination of the from, to, and by attributes and overrides those attributes if specified. Legal values are real numbers in the range 0.0-1.0. Defined in theSMIL 3.0 BasicAnimation Module. Use the calcMode attribute to determine how the values are interpreted.

calcMode

Specifies the interpolation mode of the progress of the transitionFilter. Defined inSMIL 3.0 BasicAnimation Module. ThecalcMode attribute may take any of the following values:

discrete: This specifies that the transitionFilter progress will jump from one value to the next without any interpolation.
linear: Simple linear interpolation between values is used to calculate the progress of the transitionFilter. This is the default.
paced: This value will be ignored if specified for a transitionFilter element. The default value ("linear") will be used instead.

targetElement

This attribute specifies the target element to be animated. The attribute value must be the value of an XML identifier attribute of an element (i.e. an "IDREF") within the host document. For a formal definition of IDREF, refer to XML 1.1[XML11].

href

This attribute specifies the target element to be animated. The attribute value must be an XLink locator, referring to the target element to be animated.

When integrating transitionFilter elements into the host language, thelanguage designer should avoid including both of these attributes. Ifhowever, the host language designer chooses to include both attributes in thehost language, then when both are specified for a given animation element theXLinkhref attributetakes precedence over thetargetElementattribute.

This section is informative.

The advantage of using thetargetElementattribute is the simpler syntax of the attribute value compared to thehref attribute. Theadvantage of using the XLinkhref attribute is that it isextensible to a full linking mechanism in future versions of SMILTransitions, and the animation element may be processed by generic XLinkprocessors. The XLink form is also provided for host languages that aredesigned to use XLink for all such references. The following two examplesillustrate the two approaches.

This example uses the simplertargetElementsyntax:

<transitionFilter targetElement="foo" .../>

This example uses the more flexible XLink locater syntax, with theequivalent target:

<transitionFilter xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#foo" .../>

When using an XLinkhref attribute on atransitionFilter element, the following additional XLink attributes may bedefined in the host language. These may be defined in a DTD, or the hostlanguage may require these in the document syntax to support generic XLinkprocessors. For more information, refer to[XLINK].

The following XLink attributes are required by the XLink specification.The values are fixed, and so may be specified as such in a DTD. All otherXLink attributes are optional, and do not affect SMIL Transitionssemantics.

XLink attributes for href

type: Must besimple. Identifies the type of XLink being used.
actuate: Must beonLoad. Indicates that the link to the target element is followed automatically (i.e., without user action).
show: Must beembed. Indicates that the reference does not include additional content in the file.

Additional details on the target element specification as relates to thehost document and language are described in theIntegration section.

Media Element fill="transition"
fill: This module adds the "transition" value to the possible values of the fill attribute defined on media in theSMIL Timing and Synchronization Module. This is the same attribute as specified in the BasicTransitions module.

Element content

ThetransitionFilterelement may have the param element as a child.

This section is informative.

Examples of thetransitionFilterelement

Example 1: transitionFilter slide show

The following example uses inline transitions to provide a slideshow thatincludes transitions between the images, similar to the example discussed inthe introduction. The presentation plays as follows.

Beginning at 0 seconds, butterfly displays for 5 seconds.
At 5 seconds butterfly freezes due to the fill="transition" specified on it and the 1-second left-to-right wipe from butterfly into eagle occurs.
At 6 seconds, eagle is fully displayed and remains displayed for 4 more seconds.
At 10 seconds eagle freezes due to the fill="transition" and the 1-second left-to-right wipe from eagle to wolf occurs.
At 11 seconds, wolf is fully displayed and remains displayed for 4 more seconds.
At 15 seconds wolf freezes due to the fill="transition" and the 1-second left-to-right wipe from wolf to seal occurs.
At 16 seconds, seal is fully displayed and remains displayed for 4 more seconds.
At 20 seconds the presentation ends.

...<seq>    <img xml:id="butterfly" src="butterfly.jpg" dur="5s" fill="transition" />    <img xml:id="eagle" src="eagle.jpg" dur="5s" fill="transition" >        <transitionFilter type="barWipe" subtype="leftToRight" dur="1s" />    </img>    <img xml:id="wolf" src="wolf.jpg" dur="5s" fill="transition" >        <transitionFilter type="barWipe" subtype="leftToRight" dur="1s" />    </img>    <img xml:id="seal" src="seal.jpg" dur="5s" >        <transitionFilter type="barWipe" subtype="leftToRight" dur="1s" />    </img></seq>...

Example 2: transitionFilter discrete clock transition

The following example uses a values list and discrete calcMode to specifythe progress of the transition in 12 steps. The transition begins 2 secondsafter the video begins and continues for 12 seconds. Since the transition iscircular, the effect is that of a clock-wipe that reveals one hour on theclock face at a time.

<video xml:id="video1" src="car.avi" ... >    <transitionfilter xml:id="trans1"         type="ellipseWipe" subtype="circle"          begin="2" dur="12" calcMode="discrete"          values="0.083; 0.166; 0.250; 0.333; 0.416; 0.500;             0.583; 0.666; 0.750; 0.833; 0.916; 1.000"/></video>

Example 3: transitionFilter from and to

The following example uses a partial transition that progresses from 0 to50% (0.5) complete. It assumes that the video is positioned directly on topof the image in the layout. The presentation plays as follows.

Beginning at 0 seconds the car displays. The image begins as well, but is not visible because it is behind the video.
At 1 second the transition begins to wipe away the car and reveal the background image. Over the duration of the transition (2 seconds) the wipe proceeds clockwise from the 12 o'clock position revealing 50% of the image behind the car, up through the 6 o'clock position.
At 3 seconds the car and transition both end, revealing all of racing.jpg.
At 5 seconds the image ends.

<par>        <img src="racing.jpg" begin="0s" dur="5s" />    <video xml:id="car" src="car.avi" begin="0s" dur="3s"        <transitionfilter type="clockWipe" subtype="clockwiseTwelve"             begin="1s" dur="2s" from="0.0" to="0.5" />    </video></par>

11.7.2 The param element

The transitionFilter element may take theparam element, defined in theSMIL MediaParamModule, as a child element. This element may be included from HTML orfrom some other module, depending upon the profile of the host language. Theparam element defines parameter information specific to the individualtransitionFilter. For example, the implementation of a windshieldWipe couldtake a parameter that defines the length of the radius for the wipe asfollows:

<transitionfilter type="windshieldWipe"    begin="4" dur="3" from="0.5" to="1.0" >    <param name="radius" value="3in" /></transitionFilter>

Support of the param element is implementation-dependent. The meaning ofthe parameters depends upon the implementation of the specific transition.

11.8TransitionModifiers Module

This section is normative.

The TransitionModifiers module gives additional control over the visualeffect of the transition: controlling the horizontal and vertical repeatpattern, and controlling the visual effect along the pattern border. TheSMPTE standard also allows for this type of geometric control.

This module requires either theBasicTransitions Module or theInlineTransitions Module.

horzRepeat: This attribute specifies how many times to perform the transition pattern along the horizontal axis.
The default value is 1 (the pattern occurs once horizontally).
vertRepeat: This attribute specifies how many times to perform the transition pattern along the vertical axis.
The default value is 1 (the pattern occurs once vertically).
borderWidth: This attribute specifies the width of a generated border along a wipe edge. Legal values are integers greater than or equal to 0. If borderWidth is equal to 0, then no border should be generated along the wipe edge.
The default value is 0.
borderColor: If the value of thetype attribute is not "fade", then this attribute specifies the content of the generated border along a wipe edge. Legal color values are CSS2 color values[CSS2-color-values] or the string "blend". If the value of this attribute is a color, then the generated border along the wipe or warp edge is filled with this color. If the value of this attribute is "blend", then the generated border along the wipe blend is an additive blend (or blur) of the media sources. The default value is "black".

11.8.1 Horizontal and Vertical Pattern Repeat

Using the horzRepeat and vertRepeat attributes, the geometric patternwhich makes up the transition may be repeated in both the horizontal andvertical directions over the area occupied by the media. To achieve therepeat, the area occupied by the destination media is divided into equalsections horizontally and/or vertically according to the values of horzRepeatand vertRepeat. Identical transitions are then performed, one in each of theresulting sections, at the same time.

The following diagrams illustrate the difference between the behaviorprovided by the default horzRepeat and vertRepeat attributes and eachattribute with two copies of the transition applied to an image.

Image without any transition applied

Figure 1. An image that does not have any transitions applied to it.

Default Vertical Repeat

Figure 2. The image from Figure 1 with a fan transition in progress. Thecurrent area of the transition is illustrated by the black triangle. Thisexample uses the default value of one for both horzRepeat and vertRepeat,which yields one occurrence of the transition. Therefore, the fan pattern isnot repeated in either direction.

This animated image illustrates thesingle fan transition from Figure 2. The fan transition could be declared asfollows:

<transition ... type="fanWipe" subtype="centerTop" dur="1s"/>

Horizontal Repeat of two

Figure 3. The same fan transition from Figure 2 in progress, but with twohorizontal repetitions (horzRepeat="2"). The repeat yields two smaller, butidentical copies of the transition, one in the left half of the image and onein the right half of the image. The number of patterns in the horizontaldirection equals horzRepeat.

Vertical Repeat of two

Figure 4. The same fan transition from Figure 2 in progress, but with twovertical repetitions (vertRepeat="2"). The repeat yields two smaller, butidentical copies of the transition, one in the top half of the image and onein the bottom half of the image. The number of patterns in the verticaldirection equals vertRepeat.

The following example shows the declaration of the transition from Figure4. It specifies a vertRepeat value of 2 which indicates that the fantransition will occur in two locations on the media at once.

<transition ... type="fanWipe" subtype="centerTop" dur="1s"        horzRepeat="1" vertRepeat="2"/>

Note that we didn't have set to horzRepeat to one, since one is thedefault value, but we explicitly set it here for clarity. This transition isillustrated bythis animated image.

In a more complex example, if horzRepeat was set to 3 and vertRepeat wasset to 2 then 6 small fan transitions would occur at once over the media, ina pattern of 3 wide (horzRepeat) and 2 high (vertRepeat).

Note that the horzRepeat and vertRepeat attributes might not produce avisual change depending on the type of transition. Specifically, theseattributes have no visual affect if replicating the transition patternproduces identical results. For example, a vertRepeat attribute set equal totwo would have no visual impact on a left-to-right push- or slideWipe becausethe transition would still occur from the left edge all the way to the rightedge of the media. In contrast, the same vertRepeat attribute would affect atop-to-bottom push- or slideWipe because one transition would occur from thetop to the middle of the media and the other transition would occur from themiddle to the bottom of the media at the same time. Neither horzRepeat norvertRepeat affect a fade transition because the fade applies uniformlyregardless of how many times it is replicated.

Implementations may choose to optimize by ignoring the horzRepeat andvertRepeat attributes in cases where they would have no effect.

11.9Integration

This section is normative.

The purpose of this section is to specify requirements and recommendationson the host language or profile in order to integrate SMIL Transitions.

Profiles that include theTransitionModifiers Module must also include either theBasicTransitions Module or theInlineTransitions Module.
Since transitions are applied to media and are not specific to the layout of that media, then SMIL Transitions are layout agnostic. Any type of layout language may be used.
Profiles that include theBasicTransitions Module must have some method of specifying thetransition element. It is recommended that alltransition elements be specified in the<head> of the document (if one exists) and also that there be some sort of container element which groups all thetransition elements together (similar to the<layout> element in the<head> of SMIL 1.0 documents).
A profile integrating theBasicTransitions Module must provide a means of declaring an XML identifier ontransition elements.
A profile integrating theInlineTransitions Module module must provide a means of declaring an XML identifier ontransitionFilter elements.
The profile must define what overlapping in the layout means for fill="transition" (required in theBasicTransitions Module and theInlineTransitions Module).
If the profile includes theInlineTranstions Module, then the host language designer must choose whether to support thetargetElement attribute or the XLink attributes for specifying the target element. Note that if the XLink syntax is used, the host language designer must decide how to denote the XLink namespace for the associated attributes. The namespace may be fixed in a DTD, or the language designer may require colonized attribute names (qnames) to denote the XLink namespace for the attributes. The required XLink attributes have fixed values, and so may also be specified in a DTD, or may be required on the animation elements. Host language designers may require that the optional XLink attributes be specified. These decisions are left to the host language designer - the syntax details for XLink attributes do not affect the semantics of SMIL Transitions.

11.10Appendix: Taxonomy Tables

Table 1: The Taxonomy Tablecontains a detailed list of transition type and subtype names. The names ofthe types and subtypes have been chosen so that the name provides some hintof the visual effect of the transition. However, in some cases, the namealone is not enough to visually describe these transitions. For a betterunderstanding of these transitions, please see pages 11-16 of SMPTE 258M-1993[SMPTE-EDL].

As an assistance to the reader in identifying the patterns of the SMPTEtransitions this Appendix also provides illustrations of the correspondingSMPTE wipes in the following tables.

Table 2: SMPTE Edge Wipes
Table 3: SMPTE Iris Wipes
Table 4: SMPTE Clock Wipes
Table 5: SMPTE Matrix Wipes

In the case of any discrepancies between type and subtype names in theTaxonomy Table and in the illustrated tables, the Taxonomy Table takesprecedence. The SMPTE specification[SMPTE-EDL] takes precedence over theillustrated tables in this appendix. The illustrations are provided forconvenience only.

11.10.1Table 1: The Taxonomy Table

The SMPTE Wipe Codes (where appropriate) are provided in parentheses afterthe subtype name and are for reference only. The Wipe Codes are not part ofthe transition subtype name. The default transition subtype for each type isindicated by the word [default].

Transition type	Transition subtypes (SMPTE Wipe Codes in parentheses)
Edge Wipes - wipes occur along an edge
"barWipe"	"leftToRight" (1) [default], "topToBottom" (2)
"boxWipe"	"topLeft" (3) [default], "topRight" (4), "bottomRight" (5), "bottomLeft" (6), "topCenter" (23), "rightCenter" (24), "bottomCenter" (25), "leftCenter" (26)
"fourBoxWipe"	"cornersIn" (7) [default], "cornersOut" (8)
"barnDoorWipe"	"vertical" (21) [default], "horizontal" (22), "diagonalBottomLeft" (45), "diagonalTopLeft" (46)
"diagonalWipe"	"topLeft" (41) [default], "topRight" (42)
"bowTieWipe"	"vertical" (43) [default], "horizontal" (44)
"miscDiagonalWipe"	"doubleBarnDoor" (47) [default], "doubleDiamond" (48)
"veeWipe"	"down" (61) [default], "left" (62), "up" (63), "right" (64)
"barnVeeWipe"	"down" (65) [default], "left" (66), "up" (67), "right" (68)
"zigZagWipe"	"leftToRight" (71) [default], "topToBottom" (72)
"barnZigZagWipe"	"vertical" (73) [default], "horizontal" (74)
Iris Wipes - shapes expand from the center of the media
"irisWipe"	"rectangle" (101) [default], "diamond" (102)
"triangleWipe"	"up" (103) [default], "right" (104), "down" (105), "left" (106)
"arrowHeadWipe"	"up" (107) [default], "right" (108), "down" (109), "left" (110)
"pentagonWipe"	"up" (111) [default], "down" (112)
"hexagonWipe"	"horizontal" (113) [default], "vertical" (114)
"ellipseWipe"	"circle" (119) [default], "horizontal" (120), "vertical" (121)
"eyeWipe"	"horizontal" (122) [default], "vertical" (123)
"roundRectWipe"	"horizontal" (124) [default], "vertical" (125)
"starWipe"	"fourPoint" (127) [default], "fivePoint" (128), "sixPoint" (129)
"miscShapeWipe"	"heart" (130) [default], "keyhole" (131)
Clock Wipes - rotate around a center point
"clockWipe"	"clockwiseTwelve" (201) [default], "clockwiseThree" (202), "clockwiseSix" (203), "clockwiseNine" (204)
"pinWheelWipe"	"twoBladeVertical" (205) [default], "twoBladeHorizontal" (206), "fourBlade" (207)
"singleSweepWipe"	"clockwiseTop" (221) [default], "clockwiseRight" (222), "clockwiseBottom" (223), "clockwiseLeft" (224), "clockwiseTopLeft" (241), "counterClockwiseBottomLeft" (242), "clockwiseBottomRight" (243), "counterClockwiseTopRight" (244)
"fanWipe"	"centerTop" (211) [default], "centerRight" (212), "top" (231), "right" (232), "bottom" (233), "left" (234)
"doubleFanWipe"	"fanOutVertical" (213) [default], "fanOutHorizontal" (214), "fanInVertical" (235), "fanInHorizontal" (236)
"doubleSweepWipe"	"parallelVertical" (225) [default], "parallelDiagonal" (226), "oppositeVertical" (227), "oppositeHorizontal" (228), "parallelDiagonalTopLeft" (245), "parallelDiagonalBottomLeft" (246)
"saloonDoorWipe"	"top" (251) [default], "left" (252), "bottom" (253), "right" (254)
"windshieldWipe"	"right" (261) [default], "up" (262), "vertical" (263), "horizontal" (264)
Matrix Wipes - media is revealed in squares following a pattern
"snakeWipe"	"topLeftHorizontal" (301) [default], "topLeftVertical" (302), "topLeftDiagonal" (303), "topRightDiagonal" (304), "bottomRightDiagonal" (305), "bottomLeftDiagonal" (306)
"spiralWipe"	"topLeftClockwise" (310) [default], "topRightClockwise" (311), "bottomRightClockwise" (312), "bottomLeftClockwise" (313), "topLeftCounterClockwise" (314), "topRightCounterClockwise" (315), "bottomRightCounterClockwise" (316), "bottomLeftCounterClockwise" (317)
"parallelSnakesWipe"	"verticalTopSame" (320), [default] "verticalBottomSame" (321), "verticalTopLeftOpposite" (322), "verticalBottomLeftOpposite" (323), "horizontalLeftSame" (324), "horizontalRightSame" (325), "horizontalTopLeftOpposite" (326), "horizontalTopRightOpposite" (327), "diagonalBottomLeftOpposite" (328), "diagonalTopLeftOpposite" (329)
"boxSnakesWipe"	"twoBoxTop" (340) [default], "twoBoxBottom" (341), "twoBoxLeft" (342), "twoBoxRight" (343), "fourBoxVertical (344), "fourBoxHorizontal" (345)
"waterfallWipe"	"verticalLeft" (350) [default], "verticalRight" (351), "horizontalLeft" (352), "horizontalRight" (353)
Non-SMPTE Wipes
"pushWipe"	"fromLeft" [default], "fromTop", "fromRight", "fromBottom"
"slideWipe"	"fromLeft" [default], "fromTop", "fromRight", "fromBottom"
"fade"	"crossfade" [default], "fadeToColor", "fadeFromColor"
Audio
"audioFade"	"fade" [default]
"audioVisualFade"	"crossfade" [default], "fadeToColor", "fadeFromColor"

Descriptions of non-SMPTE Transitions

The "pushWipe" transitions looks as if the destination media "pushes" thebackground media away. In other words, both the background media and thedestination media are moving.

In the "slideWipe" transitions, the destination media moves, but thebackground media does not. The visual effect of "slideWipe" transitions isthat the destination media is "sliding" in across the background media.

The "fade" transitions are pixel-by-pixel blends between the destinationmedia and either the background media or a specified color. The "fadeToColor"and "fadeFromColor" subtypes are equivalent. The fade direction is determinedby whether it is used astransIn ortransOut.

11.10.2Table 2: SMPTE Edge Wipes

Edge wipes start from a horizontal, vertical, or diagonal edge and expandin a given shape. The direction of change is to increase the white area.

"barWipe"
"leftToRight" (1) [default]	"topToBottom" (2)
"boxWipe"
"topLeft" (3) [default] "bottomRight" (5) "topCenter" (23) "bottomCenter" (25)	"topRight" (4) "bottomLeft" (6) "rightCenter" (24) "leftCenter" (26)
"fourBoxWipe"
"cornersIn" (7) [default]	"cornersOut" (8)
"barnDoorWipe"
"vertical" (21) [default] "diagonalBottomLeft" (45)	"horizontal" (22) "diagonalTopLeft" (46)
"diagonalWipe"
"topLeft" (41) [default]	"topRight" (42)
"bowTieWipe"
"vertical" (43) [default]	"horizontal" (44)
"miscDiagonalWipe"
"doubleBarnDoor" (47) [default]	"doubleDiamond" (48)
"veeWipe"
"down" (61) [default] "up" (63)	"left" (62) "right" (64)
"barnVeeWipe"
"down" (65) [default] "up" (67)	"left" (66) "right" (68)
"zigZagWipe"
"leftToRight" (71) [default]	"topToBottom" (72)
"barnZigZagWipe"
"vertical" (73) [default]	"horizontal" (74)

11.10.3Table 3: SMPTE Iris Wipes

Iris wipes expand in a given shape from the center of the media. Thedirection of change is to increase the white area.

"irisWipe"
"rectangle" (101) [default]	"diamond" (102)
"triangleWipe"
"up" (103) [default] "down" (105)	"right" (104) "left" (106)
"arrowHeadWipe"
"up" (107) [default] "down" (109)	"right" (108) "left" (110)
"pentagonWipe"
"up" (111) [default]	"down" (112)
"hexagonWipe"
"horizontal" (113) [default]	"vertical" (114)
"ellipseWipe"
"circle" (119) [default] "vertical" (121)	"horizontal" (120)
"eyeWipe"
"horizontal" (122) [default]	"vertical" (123)
"roundRectWipe"
"horizontal" (124) [default]	"vertical" (125)
"starWipe"
"fourPoint" (127) [default] "sixPoint" (129)	"fivePoint" (128)
"miscShapeWipe"
"heart" (130) [default]	"keyhole" (131)

11.10.4Table 4: SMPTE Clock Wipes

Clock wipes rotate around a center point. The center of rotation isindicated in the following illustrations by thesymbol. The arrow curved arrow shows the direction ofrotation. The direction of change is to increase the white area.

"clockWipe"
"clockwiseTwelve" (201) [default] "clockwiseSix" (203)	"clockwiseThree" (202) "clockwiseNine" (204)
"pinWheelWipe"
"twoBladeVertical" (205) [default] "fourBlade" (207)	"twoBladeHorizontal" (206)
"singleSweepWipe"
"clockwiseTop" (221) [default] "clockwiseBottom" (223) "clockwiseTopLeft" (241) "clockwiseBottomRight" (243)	"clockwiseRight" (222) "clockwiseLeft" (224) "counterClockwiseBottomLeft" (242) "counterClockwiseTopRight" (244)
"fanWipe"
"centerTop" (211) [default] "top" (231) "bottom" (233)	"centerRight" (212) "right" (232) "left" (234)
"doubleFanWipe"
"fanOutVertical" (213) [default] "fanInVertical" (235)	"fanOutHorizontal" (214) "fanInHorizontal" (236)
"doubleSweepWipe"
"parallelVertical" (225) [default] "oppositeVertical" (227) "parallelDiagonalTopLeft" (245)	"parallelDiagonal" (226) "oppositeHorizontal" (228) "parallelDiagonalBottomLeft" (246)
"saloonDoorWipe"
"top" (251) [default] "bottom" (253)	"left" (252) "right" (254)
"windshieldWipe"
"right" (261) [default] "vertical" (263)	"up" (262) "horizontal" (264)

11.10.5Table 5: SMPTE Matrix Wipes

Matrix wipes reveal media in squares following a pattern. The arrow showsthe pattern.

"snakeWipe"
"topLeftHorizontal" (301) [default] "topLeftDiagonal" (303) "bottomRightDiagonal" (305)	"topLeftVertical" (302) "topRightDiagonal" (304) "bottomLeftDiagonal" (306)
"spiralWipe"
"topLeftClockwise" (310) [default] "bottomRightClockwise" (312) "topLeftCounterClockwise" (314) "bottomRightCounterClockwise" (316)	"topRightClockwise" (311) "bottomLeftClockwise" (313) "topRightCounterClockwise" (315) "bottomLeftCounterClockwise" (317)
"parallelSnakesWipe"
"verticalTopSame" (320) [default] "verticalTopLeftOpposite" (322) "horizontalLeftSame" (324) "horizontalTopLeftOpposite" (326) "diagonalBottomLeftOpposite" (328)	"verticalBottomSame" (321) "verticalBottomLeftOpposite" (323) "horizontalRightSame" (325) "horizontalTopRightOpposite" (327) "diagonalTopLeftOpposite" (329)
"boxSnakesWipe"
"twoBoxTop" (340) [default] "twoBoxLeft" (342) "fourBoxVertical (344)	"twoBoxBottom" (341) "twoBoxRight" (343) "fourBoxHorizontal" (345)
"waterfallWipe"
"verticalLeft" (350) [default] "horizontalLeft" (352)	"verticalRight" (351) "horizontalRight" (353)