This
specification
defines
two
profiles
of
[
ttml2
]:
a
text-only
profile
and
an
image-only
profile.
These
profiles
are
intended
to
be
used
across
subtitle
and
caption
delivery
applications
worldwide,
thereby
simplifying
interoperability,
consistent
rendering
and
conversion
to
other
subtitling
and
captioning
formats.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
GitHub
Issues
are
preferred
for
discussion
of
this
specification.
Alternatively,
you
can
send
comments
to
our
mailing
list.
Please
send
them
to
public-tt@w3.org
(
archives
)
with
[imsc]
at
the
start
of
your
email's
subject
.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This
specification
defines
two
profiles
of
[
ttml2
]:
a
text-only
profile
and
an
image-only
profile.
These
profiles
are
intended
for
subtitle
and
caption
delivery
worldwide,
including
dialog
language
translation,
content
description,
captions
for
deaf
and
hard
of
hearing,
etc.
This
specification
maintains
the
scope
of
[
ttml-imsc1.1
]
while
adding
the
minimal
set
of
features
necessary
to
support
contemporary
practices
for
worldwide
subtitling
and
captioning
delivery.
The
specification
is
designed
such
that:
a
valid
Text
Profile
document
as
specified
in
[
ttml-imsc1.1
]
is
a
valid
Text
Profile
document
as
specified
herein;
a
valid
Image
Profile
document
as
specified
in
[
ttml-imsc1.1
]
is
a
valid
Image
Profile
document
as
specified
herein;
a
processor
defined
herein
transforms
a
Document
Instance
as
specified
in
[
ttml-imsc1.1
]
as
it
would
have
been
transformed
by
a
processor
defined
in
[
ttml-imsc1.1
];
and
whenever
possible,
extensions
defined
in
[
ttml-imsc1.1
]
are
(i)
replaced
by
their
[
ttml2
]
equivalent
and
(ii)
deprecated.
This
specification
defines
a
document
exchange
format
and
associated
validation
and
presentation
requirements
for
subtitle
and
caption
delivery
worldwide,
including
dialog
language
translation,
content
description,
captions
for
deaf
and
hard
of
hearing,
etc.
It
is
based
on
[
ttml2
]
and
includes
extensions
specified
in
[
SMPTE2052-1
]
and
[
EBU-TT-D
].
Two
profiles
are
defined:
in
the
Text
Profile
,
timed
text
is
expressed
exclusively
using
code
points
defined
in
The
Unicode
Standard
,
whereas,
in
the
Image
Profile
,
timed
text
is
expressed
exclusively
using
bitmap
images.
The
clear
distinction
between
the
two
profiles
reduces
authoring
and
processing
complexity.
For
example,
it
allows
systems
to
unambiguously
specify
whether
timed
text
in
text
and/or
image
form
is
permitted.
Timed
text
in
image
form
can
be
used
in
scenarios
where
the
required
text
rendering
functionality
is
not
available,
for
example
if
the
required
fonts
can
not
be
distributed,
or
if
the
receiving
processor
has
insufficient
computing
resources
to
present
text
while
displaying
video.
They
can
also
be
used
to
achieve
a
visual
effect
that
is
beyond
the
capabilities
of
this
specification,
e.g.
illuminated
letters.
When
timed
text
in
image
and
text
form
are
simultaneously
made
available
for
presentation
to
the
consumer,
two
distinct
Document
Instances
,
one
conforming
to
the
Text
Profile
and
the
other
conforming
to
the
Image
Profile
,
are
offered
such
that
assistive
technologies
have
access
to
a
text
form
when
image
content
is
encountered.
To
improve
rendering
fidelity,
§
A.
Reference
Fonts
defines
reference
fonts
and
requires
Processors
to
support
one
or
more
fonts
with
similar
font
metrics
as
these
reference
fonts.
Similarly,
in
order
to
increase
the
confidence
that
text
will
be
presented
correctly
by
Processors
targeting
specific
languages,
§
B.
Common
Character
Sets
defines
common
character
sets
that
authors
are
encouraged
to
use.
This
specification
uses
the
same
conventions
as
[
ttml2
]
for
the
specification
of
parameter
attributes,
styling
attributes
and
metadata
elements.
In
particular:
Section
2.3
of
[
ttml2
]
specifies
conventions
used
in
the
XML
representation
of
elements;
and
Sections
7.2,
10.2
and
10.4
of
[
ttml2
]
specify
conventions
used
when
specifying
the
syntax
of
attribute
values,
such
as
in
§
8.8
Extension
Vocabulary
.
This
specification
uses
Feature
and
Extension
designations
as
defined
in
Appendices
E.1
and
F.1
at
[
ttml2
]:
when
making
reference
to
content
conformance,
these
designations
refer
to
the
syntactic
expression
or
the
semantic
capability
associated
with
each
designated
Feature
or
Extension
;
and
when
making
reference
to
processor
conformance,
these
designations
refer
to
processing
requirements
associated
with
each
designated
Feature
or
Extension
.
If
the
name
of
an
element
referenced
in
this
specification
is
not
namespace
qualified,
then
the
TT
namespace
applies
(see
§
8.3
Namespaces
.)
4.
Terms
and
Definitions
Associated
region
.
The
region
element
associated
with
an
element
according
to
the
[associate
region]
procedure
defined
in
[
ttml2
].
Character
Information
Item
.
See
Section
2.2
at
[
ttml2
].
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
SHALL
,
SHALL
NOT
,
SHOULD
,
and
SHOULD
NOT
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
SHALL
satisfy
all
normative
provisions
specified
by
the
profile;
MAY
include
any
vocabulary,
syntax
or
attribute
value
associated
with
a
Feature
or
Extension
whose
disposition
is
permitted
or
optional
in
the
profile;
SHALL
NOT
include
any
vocabulary,
syntax
or
attribute
value
associated
with
a
Feature
or
Extension
whose
disposition
is
prohibited
in
the
profile.
Note
A
Document
Instance
,
by
definition,
satisfies
the
requirements
of
Section
3.1
at
[
ttml2
],
and
hence
a
Document
Instance
that
conforms
to
a
profile
defined
herein
is
also
a
conforming
TTML1
Document
Instance.
SHALL
satisfy
the
Generic
Processor
Conformance
requirements
at
Section
3.2.1
of
[
ttml2
];
SHALL
satisfy
all
normative
provisions
specified
by
the
profile;
and
SHALL
implement
presentation
semantic
support
for
every
Feature
and
Extension
designated
as
permitted
or
permitted-deprecated
by
the
profile,
subject
to
any
additional
constraints
on
each
Feature
and
Extension
as
specified
by
the
profile.
MAY
implement
presentation
semantic
support
for
every
Feature
and
Extension
designated
as
optional
by
the
profile,
subject
to
any
additional
constraints
on
each
Feature
and
Extension
as
specified
by
the
profile.
SHALL
satisfy
the
Generic
Processor
Conformance
requirements
at
Section
3.2.1
of
[
ttml2
];
SHALL
satisfy
all
normative
provisions
specified
by
the
profile;
and
SHALL
implement
transformation
semantic
support
for
every
Feature
and
Extension
designated
as
permitted
or
or
permitted-deprecated
by
the
profile,
subject
to
any
additional
constraints
on
each
Feature
and
Extension
as
specified
by
the
profile.
MAY
implement
transformation
semantic
support
for
every
Feature
and
Extension
designated
as
optional
by
the
profile,
subject
to
any
additional
constraints
on
each
Feature
and
Extension
as
specified
by
the
profile.
A
Feature
or
Extension
currently
designated
permitted-deprecated
is
intended
to
be
designated
as
optional
or
prohibited
in
future
versions
of
this
specification.
A
Feature
or
Extension
designated
as
partially
supported
is
neither
completely
prohibited
nor
completely
permitted
.
Instead,
the
disposition
of
each
of
its
subset
Feature
or
Extension
is
specified
individually.
The
use
of
the
term
presentation
processor
(
transformation
processor
)
within
this
specification
does
not
imply
conformance
to
the
DFXP
Presentation
Profile
(DFXP
Transformation
Profile)
specified
in
[
ttml2
].
In
other
words,
it
is
not
considered
an
error
for
a
presentation
processor
(
transformation
processor
)
to
conform
to
a
profile
defined
in
this
specification
without
also
conforming
to
the
DFXP
Presentation
Profile
(DFXP
Transformation
Profile).
The
permitted
and
prohibited
dispositions
do
not
refer
to
the
specification
of
a
ttp:feature
or
ttp:extension
element
as
being
permitted
or
prohibited
within
a
ttp:profile
element.
6.
Profiles
6.1
General
Notwithstanding
special
cases,
e.g.
a
Document
Instance
that
contains
no
p
,
span
,
br
,
image
element
and
no
smpte:backgroundImage
attribute,
it
is
generally
not
possible
to
construct
a
Document
Instance
that
conforms
to
the
Text
Profile
and
Image
Profile
simultaneously,
and
it
is
not
possible
to
construct
a
Document
Instance
that
results
in
the
presentation
of
both
text
data
and
image
data.
Authors
can
use
TTML
content
verification
tools
to
detect
and
warn
about
overly
constrained
uses
of
content
and
processor
profile
attribute
vocabulary,
e.g.
warn
if
(a)
a
document
simultaneously
(i)
specifies
conformance
to
content
profile
X
and
(ii)
requires
use
of
processor
profile
Y,
and
(b)
profiles
X
and
Y
are
semantically
incompatible.
6.4.2
Override
If
one
or
more
ebuttm:conformsToStandard
elements,
as
specified
in
[
EBU-TT-M
],
are
set
to
any
of
the
following
designators,
then
the
override
content
profile
SHALL
be
set
to
the
profile
associated
with
any
one
of
the
matching
designators:
A
Document
Instance
SHALL
be
concretely
encoded
as
a
well-formed
XML
1.0
[
xml
]
document
using
the
UTF-8
character
encoding
as
specified
in
[
UNICODE
].
The
resulting
[
xml
]
document
SHOULD
NOT
contain
any
of
the
following
physical
structures:
entity
declarations
;
and
entity
references
other
than
to
predefined
entities
.
Note
These
physical
structures
are
intended
to
be
prohibited
in
future
versions
of
this
specification.
Note
The
resulting
[
xml
]
document
can
contain
character
references
,
and
entity
references
to
predefined
entities
.
8.2
Foreign
Element
and
Attributes
A
Document
Instance
MAY
contain
elements
and
attributes
that
are
neither
specifically
permitted
nor
forbidden
by
a
profile.
Document
Instances
remain
subject
to
the
content
conformance
requirements
specified
at
Section
3.1
of
[
ttml2
].
In
particular,
a
Document
Instance
can
contain
elements
and
attributes
not
in
any
TT
namespace,
i.e.
in
foreign
namespaces,
since
such
elements
and
attributes
are
pruned
by
the
algorithm
at
Section
4
of
[
ttml2
]
prior
to
evaluating
content
conformance.
Note
For
validation
purposes
it
is
good
practice
to
define
and
use
a
content
specification
for
all
foreign
namespace
elements
and
attributes
used
within
a
Document
Instance
.
8.3
Namespaces
The
following
namespaces
(see
[
xml-names
])
are
used
in
this
specification:
The
namespace
prefix
values
defined
above
are
for
convenience
and
Document
Instances
MAY
use
any
prefix
value
that
conforms
to
[
xml-names
].
The
namespaces
defined
by
this
specification
are
mutable
[
namespaceState
];
all
undefined
names
in
these
namespaces
are
reserved
for
future
standardization
by
the
W3C
.
8.4
Overflow
A
Document
Instance
SHOULD
be
authored
assuming
strict
clipping
of
content
that
falls
out
of
region
areas,
regardless
of
the
computed
value
of
tts:overflow
for
the
region.
Note
As
specified
in
[
ttml2
],
tts:overflow
has
no
effect
on
the
extent
of
the
region,
and
hence
the
total
normalized
drawing
area
S(E
n
)
at
§
11.3
Paint
Regions
.
In
typical
scenario,
the
same
video
program
(the
Related
Video
Object
)
will
be
used
for
Document
Instance
authoring,
delivery
and
user
playback.
The
mapping
from
media
time
expression
to
Related
Video
Object
above
allows
the
author
to
precisely
associate
subtitle
video
content
with
video
frames,
e.g.
around
scene
transitions.
In
circumstances
where
the
video
program
is
downsampled
during
delivery,
the
application
can
specify
that,
at
playback,
the
relative
video
object
be
considered
the
delivered
video
program
upsampled
to
is
original
rate,
thereby
allowing
subtitle
content
to
be
rendered
at
the
same
temporal
locations
it
was
authored.
the
ratio
of
the
width
to
the
height
of
the
rectangular
area
is
equal
to
the
display
aspect
ratio
of
the
Root
Container
Region
as
determined
in
Appendix
H
of
[
ttml2
];
the
center
of
the
rectangular
area
is
collocated
with
the
center
of
the
image
frame;
the
rectangular
area
is
entirely
within
the
image
frame;
and
the
rectangular
area
has
a
height
or
width
equal
to
that
of
the
image
frame.
Note
The
mapping
algorithm
above
allows
the
author
to
precisely
control
caption/subtitle
position
relative
to
elements
within
each
frame
of
the
video
program,
e.g.
to
match
the
position
of
actors.
This
mapping
algorithm
does
not
however
specify
the
presentation
of
either
the
video
frame
or
Root
Container
Region
on
the
ultimate
display
device.
This
presentation
depends
on
many
factors,
including
user
input,
and
can
involve
displaying
only
parts
of
the
content.
Authors
are
therefore
encouraged
to
follow
best
practices
for
the
intended
target
applications.
Below
are
selected
examples:
A
16:9
video
program
is
authored
to
ensure
adequate
presentation
on
4:3
display
devices
using
a
center-cut.
Accordingly
subtitle/captions
are
authored
using
ttp:displayAspectRatio="4
3"
,
allowing
the
combination
to
be
displayed
on
both
4:3
and
16:9
display
devices
while
preserving
both
caption/subtitles
content
and
the
relative
position
of
caption/subtitles
with
video
elements.
A
playback
system
zooms
the
content
of
example
(a)
to
fill
a
21:9
display,
perhaps
as
instructed
by
the
user.
The
system
elects
to
scale
the
Root
Container
Region
to
fit
vertically
within
the
display
(maintaining
its
aspect
ratio
as
authored),
at
the
cost
of
losing
relative
positioning
between
caption/subtitles
and
video
elements.
The
system
described
in
(b)
instead
elects
to
map
the
Root
Container
Region
to
the
video
frame,
maintaining
relative
positioning
between
caption/subtitles
and
video
elements
but
at
the
risk
of
clipping
subtitles/captions.
Subtitle/captions
are
authored
using
ttp:displayAspectRatio="16
9"
to
match
the
16:9
video,
but
ittp:activeArea
indicates
that
the
Active
Area
is
smaller
than
the
Root
Container
Region
.
The
system,
which
uses
a
4:3
display,
elects
to
scale
the
video
and
the
Root
Container
Region
such
that
all
of
the
subtitle/caption
content
within
the
Active
Area
is
visible,
with
positional
alignment
maintained,
at
the
cost
of
clipping
some
of
the
video.
8.8
Extension
Vocabulary
8.8.1
ittp:aspectRatio
The
#aspectRatio
feature
is
designated
as
permitted-deprecated
in
the
profiles
defined
by
this
specification.
The
#displayAspectRatio
feature
provides
equivalent
semantics.
If
present,
the
ittp:aspectRatio
attribute
SHALL
conform
to
the
following
syntax:
ittp:aspectRatio
: numerator denominator // with int(numerator) != 0 and int(denominator) != 0
// where int(s) parses string s as a decimal integer.
numerator | denominator
: <digit>+ // no linear white-space is implied or permitted
//
between
each
<digit>
token
An
ittp:aspectRatio
attribute
is
considered
to
be
significant
only
when
specified
on
the
tt
element.
If
specified
on
the
tt
element,
the
ittp:aspectRatio
attribute
specifies
the
display
aspect
ratio
of
the
Root
Container
Region
.
If
not
specified,
then
the
display
aspect
ratio
of
the
Root
Container
Region
is
determined
according
to
Appendix
H
of
[
ttml2
].
8.8.2
ittp:progressivelyDecodable
The
#progressivelyDecodable
feature
is
designated
as
permitted-deprecated
in
the
profiles
defined
by
this
specification.
A
progressively
decodable
Document
Instance
is
structured
to
facilitate
presentation
before
the
document
is
received
in
its
entirety,
and
can
be
identified
using
ittp:progressivelyDecodable
attribute.
A
progressively
decodable
Document
Instance
is
a
Document
Instance
that
conforms
to
the
following:
no
attribute
or
element
of
the
TTML
timing
vocabulary
is
present
within
the
head
element;
given
two
intermediate
synchronic
documents
A
and
B
of
the
Document
Instance
,
with
start
times
TA
and
TB
,
respectively,
TA
is
not
greater
than
TB
if
A
includes
a
p
element
that
lexically
precedes
any
p
element
that
B
includes;
no
attribute
of
the
TTML
timing
vocabulary
is
present
on
a
descendant
element
of
p
;
and
no
element
E1
explicitly
references
another
element
E2
where
the
opening
tag
of
E2
is
lexically
subsequent
to
the
opening
tag
of
E1
.
If
present,
the
ittp:progressivelyDecodable
attribute
SHALL
conform
to
the
following
syntax:
ittp:progressivelyDecodable
: "true"
|
"false"
An
ittp:progressivelyDecodable
attribute
is
considered
to
be
significant
only
when
specified
on
the
tt
element.
If
not
specified,
the
value
of
ittp:progressivelyDecodable
SHALL
be
considered
to
be
equal
to
"false"
.
[
ttml2
]
specifies
explicitly
referencing
of
elements
identified
using
xml:id
in
the
following
circumstances:
an
element
in
body
referencing
region
elements.
In
this
case,
Requirement
4
above
is
always
satisfied.
an
element
in
body
referencing
style
elements.
In
this
case,
Requirement
4
above
is
always
satisfied.
a
region
element
referencing
style
elements.
In
this
case,
Requirement
4
above
is
always
satisfied.
a
style
element
referencing
other
style
elements.
In
this
case,
Requirement
4
provides
an
optimization
of
style
element
ordering
within
the
head
element.
a
ttm:actor
element
referencing
a
ttm:agent
element.
In
this
case,
Requirement
4
provides
optimization
of
metadata
elements
ordering
within
the
document.
a
content
element
referencing
ttm:agent
elements
using
the
ttm:agent
attribute.
In
this
case,
Requirement
4
provides
optimization
of
metadata
elements
ordering
within
the
document.
8.8.3
itts:forcedDisplay
itts:forcedDisplay
can
be
used
to
hide
content
whose
computed
value
of
tts:visibility
is
"visible"
when
the
processor
has
been
configured
to
do
so
via
the
application
parameter
displayForcedOnlyMode
.
If
and
only
if
the
value
of
displayForcedOnlyMode
is
"true"
,
a
content
element
with
a
itts:forcedDisplay
computed
value
of
"false"
SHALL
NOT
produce
any
visible
rendering,
regardless
of
the
computed
value
of
tts:visibility
.
The
itts:forcedDisplay
attribute
has
no
effect
on
content
layout
or
composition,
but
merely
determines
whether
composed
content
is
visible
or
not.
The
itts:forcedDisplay
attribute
SHALL
conform
to
the
following:
Values:
false
|
true
Initial:
false
Applies
to:
body
,
div
,
p
,
region
,
span
Inherited:
yes
Percentages:
N/A
Animatable:
discrete
Annex
§
C.
Forced
content
illustrates
the
use
of
itts:forcedDisplay
in
an
application
in
which
a
single
document
contains
both
hard
of
hearing
captions
and
translated
foreign
language
subtitles,
using
itts:forcedDisplay
to
display
translation
subtitles
always,
independently
of
whether
the
hard
of
hearing
captions
are
displayed
or
hidden.
The
presentation
processor
SHALL
accept
an
optional
boolean
parameter
called
displayForcedOnlyMode
,
whose
value
MAY
be
set
by
a
context
external
to
the
presentation
processor
.
If
not
set,
the
value
of
displayForcedOnlyMode
SHALL
be
assumed
to
be
equal
to
"false"
.
The
algorithm
for
setting
the
displayForcedOnlyMode
parameter
based
on
the
circumstances
under
which
the
Document
Instance
is
presented
is
left
to
the
application.
<?xml version="1.0" encoding="UTF-8"?><ttxml:lang="en"xmlns="http://www.w3.org/ns/ttml"xmlns:ttm="http://www.w3.org/ns/ttml#metadata"xmlns:tts="http://www.w3.org/ns/ttml#styling"xmlns:ttp="http://www.w3.org/ns/ttml#parameter"xmlns:itts="http://www.w3.org/ns/ttml/profile/imsc1#styling"ttp:displayAspectRatio="16 9"ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.2/text"><head><layout><regionxml:id="r1"tts:showBackground="whenActive"tts:origin="10% 2%"tts:extent="80% 10%"tts:color="white"itts:forcedDisplay="true"tts:backgroundColor="black"/><regionxml:id="r2"tts:showBackground="whenActive"tts:origin="10% 80%"tts:extent="80% 10%"tts:color="white"tts:backgroundColor="black"/></layout></head><body><div><pregion="r1"begin="1s"end="6s">Lycée</p><!-- the following will not appear if displayForcedOnlyMode='true' --><pregion="r2"begin="4s"end="6s">Nous étions inscrits au même lycée.</p></div></body>
</
tt
>
Note
As
specified
in
[
ttml2
],
the
background
of
a
region
can
be
visible
even
if
the
computed
value
of
tts:visibility
equals
"hidden"
for
all
active
content
within.
The
background
of
a
region
for
which
itts:forcedDisplay
equals
"true"
can
therefore
remain
visible
even
if
itts:forcedDisplay
equals
"false"
for
all
active
content
elements
within
the
region
and
displayForcedOnlyMode
equals
"true"
.
Authors
can
avoid
this
situation,
for
instance,
by
ensuring
that
content
elements
and
the
regions
that
they
are
flowed
into
always
have
the
same
value
of
itts:forcedDisplay
.
Note
Although
itts:forcedDisplay
,
like
all
the
TTML
style
attributes,
has
no
defined
semantics
on
a
br
content
element,
itts:forcedDisplay
will
apply
to
a
br
content
element
if
it
is
either
defined
on
an
ancestor
content
element
of
the
br
content
element
or
it
is
applied
to
a
region
element
corresponding
to
a
region
that
the
br
content
element
is
being
flowed
into.
Note
It
is
expected
that
the
functionality
of
itts:forcedDisplay
will
be
mapped
to
a
conditional
style
construct
in
a
future
revision
of
this
specification.
Note
The
presentation
semantics
associated
with
itts:forcedDisplay
are
intended
to
be
compatible
with
those
associated
with
the
forcedDisplayMode
attribute
defined
in
[
CFF
].
8.8.4
ittm:altText
The
#altText
feature
is
designated
as
permitted-deprecated
in
the
profiles
defined
by
this
specification.
The
altText
named
metadata
item
provides
equivalent
semantics.
ittm:altText
allows
an
author
to
provide
a
text
string
equivalent
for
an
element,
typically
an
image.
This
text
alternative
MAY
be
used
to
support
indexing
of
the
content,
facilitate
quality
checking
of
the
document
during
authoring
and
make
a
Image
Profile
Document
Instance
accessible
to
timed
text
authors
with
(visual)
disabilities
in
absence
of
a
corresponding
Text
Profile
Document
Instance
.
The
ittm:altText
element
SHALL
conform
to
the
following
syntax:
<ittm:altText
xml:id = ID
xml:lang = string
xml:space = (default|preserve)
{any attribute not in the default namespace, any TT namespace or any IMSC namespace}>
Content: #PCDATA
</ittm:altText>
The
ittm:altText
element
SHALL
be
a
child
of
the
metadata
element.
<?xml version="1.0" encoding="UTF-8"?><ttxml:lang="fr"xmlns="http://www.w3.org/ns/ttml"xmlns:ttp="http://www.w3.org/ns/ttml#parameter"ttp:profile="http://www.w3.org/ns/ttml/profile/imsc1/image"xmlns:tts="http://www.w3.org/ns/ttml#styling"xmlns:smpte="http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt"xmlns:ittm="http://www.w3.org/ns/ttml/profile/imsc1#metadata"tts:extent="320px 240px"><head><layout><regionxml:id="area1"tts:origin="20px 215px"tts:extent="180px 20px"/></layout></head><body><divbegin="1s"end="9s"region="area1"smpte:backgroundImage="altText1-img.png"><metadata><ittm:altText>Nous étions inscrits au même lycée.</ittm:altText></metadata></div></body>
</
tt
>
Note
In
contrast
to
the
common
use
of
alt
attributes
in
[
HTML
],
the
ittm:altText
attribute
content
is
not
intended
to
be
displayed
in
place
of
the
element
if
the
element
is
not
loaded.
The
ittm:altText
attribute
content
can
however
be
read
and
used
by
assistive
technologies.
Under
normal
circumstances,
the
entirety
of
the
Root
Container
Region
is
presented.
However,
under
special
circumstances,
such
as
when
the
related
video
object
is
cropped,
a
system
can,
for
instance,
use
the
ittp:activeArea
parameter
to
avoid
cropping
areas
of
the
Root
Container
Region
that
are
intended
to
be
visible
to
the
viewer.
The
specific
behavior
of
the
system
is
however
left
undefined
intentionally:
the
system
can
select
a
presentation
mode
appropriate
to
the
display
shape,
user
preferences,
etc.
The
ittp:activeArea
is
analogous
to
the
Active
Format
Description
(AFD)
metadata
commonly
used
in
broadcast
applications.
The
Active
Area
is
specified
using
the
ittp:activeArea
attribute.
If
present,
the
ittp:activeArea
attribute
SHALL
conform
to
the
following
syntax:
ittp:activeArea
: leftOffset topOffset width height
leftOffset | topOffset | width | height
:
<percentage>
//
where
<percentage>
is
non-negative
and
not
greater
than
100%.
The
origin
top
left
{x,
y}
percentage
coordinates
of
the
Active
Area
SHALL
be
calculated
as
follows:
x = leftOffset * (1 - width/100)
y
=
topOffset
*
(1
-
height/100)
Note
The
use
of
left
and
top
offset
positions
is
co-incident
with
the
[
css3-background
]
background-position
property
where
a
two
percentage
value
position
is
used.
<?xml version="1.0" encoding="UTF-8"?><ttxml:lang="en"xmlns="http://www.w3.org/ns/ttml"xmlns:ttm="http://www.w3.org/ns/ttml#metadata"xmlns:tts="http://www.w3.org/ns/ttml#styling"xmlns:ttp="http://www.w3.org/ns/ttml#parameter"xmlns:ittp="http://www.w3.org/ns/ttml/profile/imsc1#parameter"ittp:activeArea="50% 50% 80% 80%"tts:extent="640px 480px"ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.2/text"><head><layout><regionxml:id="area1"tts:origin="10% 10%"tts:extent="80% 10%"tts:backgroundColor="blue"tts:displayAlign="center"tts:textAlign="center"tts:color="white"tts:fontSize="24px"/><regionxml:id="area2"tts:origin="10% 80%"tts:extent="80% 10%"tts:backgroundColor="blue"tts:displayAlign="center"tts:textAlign="center"tts:color="white"tts:fontSize="24px"/><regionxml:id="area3"tts:origin="10% 92%"tts:extent="80% 6%"tts:backgroundColor="red"tts:displayAlign="center"tts:textAlign="center"tts:color="yellow"tts:fontSize="24px"/></layout></head><body><div><pregion="area1"begin="0s"end="6s">This region is within the editorial area.</p><pregion="area2"begin="0s"end="6s">This region is within the editorial area.</p><pregion="area3"begin="0s"end="6s">This region is not.</p></div></body>
</
tt
>
8.8.6
itts:fillLineGap
The
itts:fillLineGap
attribute
allows
the
author
to
control
the
application
of
background
between
successive
line
areas.
If
itts:fillLineGap="true"
then
the
background
of
each
inline
area
generated
by
descendant
spans
of
the
p
element
SHALL
extend
to
the
before-edge
and
after-edge
of
its
containing
line
area
(
before-edge
and
after-edge
are
defined
at
Section
4.2.3
of
[
XSL11
]).
The
itts:fillLineGap
attribute
SHALL
conform
to
the
following:
Values:
false
|
true
Initial:
false
Applies
to:
p
Inherited:
yes
Percentages:
N/A
Animatable:
discrete
In
the
following
example,
the
p
specifies
itts:fillLineGap="true"
,
and,
as
a
result,
no
gap
exists
between
its
lines.
<?xml version="1.0" encoding="UTF-8"?><ttxmlns="http://www.w3.org/ns/ttml"xmlns:ttp="http://www.w3.org/ns/ttml#parameter"xmlns:tts="http://www.w3.org/ns/ttml#styling"xmlns:itts="http://www.w3.org/ns/ttml/profile/imsc1#styling"ttp:timeBase="media"xml:lang="en"ttp:cellResolution="50 30"ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.2/text"><head><styling><stylexml:id="spanStyle"tts:color="#ffffff"tts:backgroundColor="#000000" /><stylexml:id="spanStyleSmall"tts:color="#000000"tts:backgroundColor="#dfbb02"tts:fontSize="50%"/><stylexml:id="spanStyleBig"tts:color="#ffffff"tts:backgroundColor="#b75800"tts:fontSize="150%"/><stylexml:id="paragraphStyle"tts:fontFamily="monospaceSerif"tts:textAlign="center"tts:fontSize="200%"tts:lineHeight="165%"itts:fillLineGap="true"/></styling><layout><regionxml:id="bottom"tts:origin="10% 10%"tts:extent="80% 80%"tts:displayAlign="after" /></layout></head><body><div><pxml:id="subtitle1"region="bottom"begin="00:00:00.000"end="00:00:30.000"style="paragraphStyle"><spanstyle="spanStyle">##Line gaps##</span><br/><spanstyle="spanStyle">The quick </span><spanstyle="spanStyleBig">brown</span><spanstyle="spanStyle"> fox</span><br/><spanstyle="spanStyle">jumps over the </span><spanstyle="spanStyleSmall">lazy</span><spanstyle="spanStyle"> dog</span><br/><spanstyle="spanStyle">##Line gaps##</span></p></div></body>
</
tt
>
Figure
1
Illustrative
rendition
of
the
example
immediately
above
with
itts:fillLineGap="true"
removed
(left)
or
preserved
(right).
Blue
lines
have
been
added
to
show
the
before-edge
and
after-edge
of
each
line
area,
which
are
coincident
for
successive
line
areas.
Also,
as
illustrated
in
the
following
example,
because
the
line
areas
of
successive
p
elements
are
contiguous,
no
gap
exists
between
two
successive
p
elements
where
itts:fillLineGap="true"
.
Figure
2
Illustrative
rendition
of
the
example
immediately
above,
where
itts:fillLineGap="true"
on
the
two
paragraphs
of
the
top
region,
itts:fillLineGap="false"
on
the
two
paragraphs
of
the
bottom
region.
8.9
Profile
Signaling
8.9.1
General
The
ttp:contentProfiles
attribute
SHOULD
be
present
on
the
tt
element,
with
exactly
one
of
its
values
equal
to
the
designator
of
the
profile
(either
Text
Profile
or
Image
Profile
)
to
which
the
Document
Instance
conforms.
Note
The
ttp:contentProfiles
attribute
is
prohibited
in
some
profiles,
e.g.
[
EBU-TT-D
]
as
discussed
in
§
I.2
EBU-TT-D
.
Note
To
minimize
the
risk
of
incompatibility,
the
use
of
the
ttp:contentProfiles
attribute
and
other
syntax
introduced
in
[
ttml2
]
is
not
recommended
in
documents
intended
to
conform
to
profiles
that
are
based
on
[
TTML1
],
e.g.
[
SMPTE2052-1
],
[
ttml-imsc1
]
,
[
ttml-imsc1.0.1
]
,
or
[
ttml10-sdp-us
].
Note
The
ttp:contentProfiles
attribute
can
include
additional
designators,
beyond
those
specified
herein,
including
designators
for
other
versions
of
this
specification.
When
using
the
ebuttm:conformsToStandard
element
specified
in
[
EBU-TT-M
],
the
designators
of
the
Text
Profile
and
Image
Profile
SHALL
be
used
when
indicating
conformance
to
the
corresponding
profile.
The
following
style
properties
SHALL
be
subject
to
the
Style
Resolution
procedures
specified
at
Section
10.4
of
[
ttml2
]:
itts:fillLineGap
itts:forcedDisplay
ebutts:linePadding
ebutts:multiRowAlign
Note
The
style
properties
above
can
be
specified
as
attributes
of
the
initial
element
specified
at
Section
10.1.1
of
[
ttml2
].
8.12
Constraints
8.12.1
Region
8.12.1.1
Presented
Region
A
presented
region
is
a
temporally
active
region
that
satisfies
the
following
conditions:
the
computed
value
of
tts:opacity
is
not
equal
to
"0.0"
;
and
the
computed
value
of
tts:display
is
not
"none"
;
and
the
computed
value
of
tts:visibility
is
not
"hidden"
;
and
either
(a)
content
is
selected
into
the
region
or
(b)
the
computed
value
of
tts:showBackground
is
equal
to
"always"
and
the
computed
value
of
tts:backgroundColor
has
non-transparent
alpha.
8.12.1.2
Dimensions
and
Position
All
regions
SHALL
NOT
extend
beyond
the
Root
Container
Region
,
i.e.
every
coordinate
in
the
set
of
coordinates
of
each
region
is
also
in
the
set
of
coordinates
of
the
Root
Container
Region
.
A
altText
named
metadata
item
SHALL
NOT
be
present
in
a
Document
Instance
if
any
ittm:altText
element
is
also
present.
8.12.3
#altText
The
ittm:altText
element
SHOULD
NOT
be
present
unless
compatibility
with
[
ttml-imsc1.0.1
]
processors
is
desired.
A
ittm:altText
element
SHALL
NOT
be
present
in
a
Document
Instance
if
any
altText
named
metadata
item
element
is
also
present.
8.12.4
#aspectRatio
The
ittp:aspectRatio
attribute
SHOULD
NOT
be
present
in
a
Document
Instance
unless
compatibility
with
[
ttml-imsc1.0.1
]
processors
is
desired.
The
ittp:aspectRatio
attribute
SHALL
not
be
present
in
a
Document
Instance
if
any
ttp:displayAspectRatio
attribute
is
also
present.
8.12.5
#displayAspectRatio
The
ttp:displayAspectRatio
attribute
SHALL
not
be
present
in
a
Document
Instance
if
any
ittp:aspectRatio
attribute
is
also
present.
8.12.6
#extent-root
If
the
Document
Instance
includes
any
length
value
that
uses
the
px
unit,
tts:extent
SHALL
be
present
on
the
tt
element.
8.12.7
#frameRate
If
the
Document
Instance
includes
any
clock
time
expression
that
uses
the
frames
term
or
any
offset
time
expression
that
uses
the
f
metric,
the
ttp:frameRate
attribute
SHALL
be
present
on
the
tt
element.
8.12.8
#length-cell
c
units
SHALL
NOT
be
present
outside
of
the
value
of
ebutts:linePadding
.
8.12.9
#length-root-container-relative
When
specified
on
a
tts:extent
or
tts:position
attribute:
rh
units
SHALL
NOT
be
used
for
horizontal
length
components;
and
rw
units
SHALL
NOT
be
used
for
vertical
length
components.
Note
8.12.10
#tickRate
ttp:tickRate
SHALL
be
present
on
the
tt
element
if
the
document
contains
any
time
expression
that
uses
the
t
metric.
8.12.11
#timeBase-media
This
section
is
non-normative.
[
ttml2
]
specifies
that
the
default
timebase
is
"media"
if
ttp:timeBase
is
not
specified
on
tt
.
8.12.12
#time-offset-with-frames
This
section
is
non-normative.
As
specified
in
[
ttml2
],
a
#time-offset-with-frames
expression
is
translated
to
a
media
time
M
according
to
M
=
3600
·
hours
+
60
·
minutes
+
seconds
+
(frames
÷
(
ttp:frameRateMultiplier
·
ttp:frameRate
)).
8.12.13
#timing
For
any
content
element
that
contains
br
elements
or
text
nodes
or
a
smpte:backgroundImage
attribute,
both
the
begin
attribute
and
one
of
either
the
end
or
dur
attributes
SHOULD
be
specified
on
the
content
element
or
at
least
one
of
its
ancestors.
8.12.14
usesForced
named
metadata
item
This
section
is
non-normative.
The
usesForced
named
metadata
item
does
not
apply
since
the
condition
attribute
is
prohibited.
The
itts:forcedDisplay
attribute
is
used
to
specify
forced
content
semantics.
When
rendering
codepoints
matching
one
of
the
combinations
of
computed
font
family
and
codepoints
listed
in
§
A.
Reference
Fonts
,
a
processor
SHALL
use
a
font
that
generates
a
glyph
sequence
whose
dimension
is
substantially
identical
to
the
glyph
sequence
that
would
have
been
generated
by
one
of
the
specified
reference
fonts.
Note
This
clause
only
applies
to
codepoints
supported
by
the
processor.
See
§
9.2
Recommended
Character
Sets
for
codepoints
that
a
processor
is
likely
to
encounter
for
various
languages.
Note
When
a
content
author
sets
a
bounding
box
for
a
subtitle,
they
want
to
maximize
the
likelihood
that
the
text
will
fit
within
it
when
displayed
by
the
processor.
If
the
processor
doesn't
use
the
specific
font
the
content
author
had
in
mind,
the
font
actually
used
might
cause
the
text
to
grow
in
size
so
that
it
no
longer
fits
in
the
bounding
box.
This
is
further
compounded
by
differences
in
the
way
text
wraps
when
a
font
has
bigger
glyphs,
which
might
increase
the
number
of
lines
used,
and
increased
line
spacing,
which
might
also
push
some
of
the
text
outside
the
bounding
box.
To
help
ensure
that
things
such
as
text
size,
line
breaking,
and
line
height
behave
as
expected
relative
to
the
size
of
the
bounding
box
set
by
the
content
author,
the
author
can
use
one
of
the
reference
fonts
defined
by
this
specification.
This
specification
requires
processors
to
support
one
or
more
fonts
with
similar
font
metrics
as
reference
fonts.
Note
that,
however,
the
reference
fonts
as
currently
defined
only
cover
characters
used
for
a
few
writing
systems
–
in
particular,
a
subset
of
those
based
on
Latin,
Greek,
Cyrillic,
Hebrew,
and
Arabic
scripts.
Note
Implementations
can
use
fonts
other
than
those
specified
in
§
A.
Reference
Fonts
.
Two
fonts
with
equal
metrics
can
have
a
different
appearance,
but
flow
identically.
The
named
color
green
defined
in
[
ttml2
]
is
equivalent
to
the
RGB
color
triple
#008000
and
is
not
full
luminance.
For
full
luminance
green,
an
author
can
specify
the
RGB
color
triple
#00ff00
or
the
named
color
lime
.
9.5.2
#extent-region
For
each
region
element
defined
in
the
Document
Instance
,
the
specified
value
of
the
tts:extent
style
property
SHALL
consist
of
two
length
expressions
that
use
pixel
(px),
percentage
(%),
or
root
container
relative
units.
The
requirement
above
requires
the
author
to
explicitly
specify
the
value
of
tts:extent
in
the
Document
Instance
,
e.g.
by
specifying
the
tts:extent
attribute
for
each
region
element.
All
source
elements
that
are
children
of
a
font
element
SHALL
reference
an
external
data
resource
.
Note
Note
A
Processor
MAY
use
the
[
css-fonts-3
]
§5
font
matching
algorithm
for
associating
a
font
with
a
run
of
text.
Note
9.5.4
#fontFamily-generic
In
absence
of
specific
instructions
on
the
choice
of
font
families,
and
in
order
to
enhance
reproducibility
of
line
fitting,
authors
are
encouraged
to
use
the
monospaceSerif
or
proportionalSansSerif
generic
font
families,
for
which
reference
font
metrics
are
defined
at
§
A.
Reference
Fonts
.
If
the
computed
value
of
tts:fontFamily
is
"default"
,
then
the
used
value
of
tts:fontFamily
SHALL
be
"monospaceSerif"
.
Note
The
term
used
value
is
defined
in
CSS
2.1,
as
normatively
referenced
by
[
ttml2
].
9.5.5
#fontFamily
Linear
white-space
SHOULD
NOT
appear
between
components
of
the
specified
value
of
tts:fontFamily
.
9.5.6
#length-negative
Strictly
negative
length
expressions
SHALL
NOT
be
used
with
attributes
other
than:
tts:disparity
;
and
tts:textShadow
.
Note
9.5.7
#lineHeight
The
specified
value
of
the
tts:lineHeight
attribute
SHOULD
be
such
that
specified
style
set
of
each
p
element
contains
a
tts:lineHeight
property
whose
value
is
not
normal
.
Note
Implementation
of
the
normal
value
is
not
uniform
at
the
time
of
this
writing.
9.5.8
#origin
The
value
of
the
tts:origin
attribute
SHALL
consist
of
two
length
expressions
that
use
pixel
(px)
or
percentage
(%)
units.
If
the
tts:position
attribute
is
specified
anywhere
in
a
Document
Instance
,
then
the
tts:origin
attribute
SHALL
NOT
be
specified
anywhere
in
that
Document
Instance
.
9.5.9
#position
All
length
components
of
the
value
of
a
tts:position
attribute
SHALL
use
pixel
(px),
percentage
(%)
or
root
container
relative
units.
If
the
tts:origin
attribute
is
specified
anywhere
in
a
Document
Instance
,
then
the
tts:position
attribute
SHALL
NOT
be
specified
anywhere
in
that
Document
Instance
.
9.5.10
#resources
The
resources
element
SHALL
not
contain
any
of
the
following
children
elements:
audio
;
data
;
and
image
.
9.5.11
#rubyAlign
The
specified
value
of
the
tts:rubyAlign
attribute
SHALL
be
such
that
its
computed
value
is
center
or
spaceAround
.
9.5.12
#textOutline-unblurred
The
specified
value
of
the
tts:textOutline
attribute
SHALL
be
such
that
its
computed
value
on
any
span
element
is
10%
or
less
than
the
computed
value
of
tts:fontSize
attribute
on
the
same
element.
9.5.13
#textShadow
The
specified
value
of
the
tts:textShadow
attribute
SHALL
NOT
have
more
than
4
<shadow>
values.
9.5.14
ebutts:linePadding
In
addition
to
the
style
element,
the
attribute
ebutts:linePadding
MAY
be
specified
on
the
following
elements:
In
contrast
to
this
specification,
[
EBU-TT-D
]
specifies
that
the
attribute
ebutts:multiRowAlign
is
allowed
only
on
the
style
element.
9.5.16
Slanted
Japanese-language
text
This
section
is
non-normative.
Since
(a)
Japanese-language
fonts
typically
do
not
include
italic
or
oblique
faces,
and
(b)
Japanese-language
slanted
vertical
text
consists
of
characters
slanted
in
the
vertical
direction
(and
not
in
the
horizontal
direction),
it
is
recommended
that
tts:shear
be
specified
to
slant
Japanese-language
text
–
instead
of
specifying
tts:fontStyle="italic"
or
tts:fontStyle="oblique"
.
10.
Image
Profile
Provisions
10.1
Profile
Designator
This
profile
is
associated
with
the
following
profile
designator:
Profile
Name
Profile
Designator
IMSC
1.1
Image
http://www.w3.org/ns/ttml/profile/imsc1.1/image
Note
This
profile
designator
remains
unchanged
from
[
ttml-imsc1.1
]
since
this
specification
makes
no
substantive
changes
to
the
Image
Profile.
10.2
Presented
Image
10.2.1
Definition
A
presented
image
is
a
div
element:
with
a
smpte:backgroundImage
attribute
or
a
child
image
element;
and
10.2.3
Intermediate
Synchronic
Document
Construction
For
the
purposes
of
constructing
an
intermediate
synchronic
document
,
a
div
element
with
a
smpte:backgroundImage
attribute
SHALL
NOT
be
considered
empty.
10.3
Image
Resources
An
image
resource
is
a
PNG
datastream
as
specified
in
[
PNG
].
If
a
pHYs
chunk
is
present,
it
SHALL
indicate
square
pixels.
Note
[
PNG
]
specifies
that,
if
no
pixel
aspect
ratio
is
carried,
the
default
of
square
pixels
is
assumed.
10.4
Constraints
10.4.1
#content
The
p
,
span
and
br
elements
SHALL
NOT
be
present.
Sections
below
specify
constraints
on
div
elements.
10.4.2
#extent-region
The
tts:extent
attribute
SHALL
be
present
on
each
region
element
defined
in
the
Document
Instance
and
its
value
SHALL
consist
of
two
length
expressions
that
use
pixel
(px)
units.
10.4.3
#length-negative
Strictly
negative
length
expressions
SHALL
NOT
be
used
with
attributes
other
than:
A
div
element
that
contains
a
child
image
element
SHOULD
contain
a
metadata
element
containing
an
altText
named
metadata
item
that
is
a
text
alternative
of
the
image
resource
referenced
by
the
image
element.
An
image
element
SHALL
specify
a
src
attribute,
which
references
an
image
resource
that
conforms
to
§
10.3
Image
Resources
.
An
image
element
SHALL
specify
a
type
attribute.
An
image
element
SHALL
specify
a
tts:extent
attribute,
which
shall
be
equal
to:
the
specified
value
of
the
tts:extent
style
property
of
the
region
element
in
which
the
image
element
is
presented;
and
the
dimensions
(in
pixels)
of
the
image
resource.
10.4.5
SMPTE
#image
Extension
10.4.5.1
smpte:backgroundImage
smpte:backgroundImage
MAY
be
used
with
the
semantics
of
the
attribute
defined
by
Sections
5.5.2
of
[
SMPTE2052-1
].
If
a
smpte:backgroundImage
attribute
is
applied
to
a
div
element:
the
width
and
height
(in
pixels)
of
the
image
resource
referenced
by
smpte:backgroundImage
SHALL
be
equal
to
the
width
and
height
expressed
by
the
tts:extent
attribute
of
the
region
in
which
the
div
element
is
presented;
the
div
element
SHOULD
contain
a
metadata
element
containing
an
ittm:altText
element
that
is
a
text
alternative
of
the
image
referenced
by
the
smpte:backgroundImage
attribute;
The
smpte:backgroundImage
attribute
SHALL
reference
an
image
resource
that
conforms
to
§
10.3
Image
Resources
;
and
the
div
element
SHALL
NOT
have
any
image
element
as
a
descendant.
Note
In
order
to
individually
position
multiple
div
elements,
each
div
can
be
associated
with
a
distinct
region
with
the
desired
tts:extent
and
tts:origin
.
Note
The
rendering
semantics
of
smpte:backgroundImage
are
not
identical
to
those
of
background-image
specified
at
Section
7.8.3
of
[
XSL11
].
In
particular,
Section
5.5.6
at
[
SMPTE2052-1
]
amends
the
semantics
of
background-image
by
specifying
values
for
its
min-height
and
min-width
properties.
10.4.5.2
smpte:backgroundImageHorizontal
and
smpte:backgroundImageVertical
smpte:backgroundImageHorizontal
and
smpte:backgroundImageVertical
SHALL
NOT
be
used.
10.4.5.3
smpte:image
smpte:image
SHALL
NOT
be
used.
11.
Hypothetical
Render
Model
11.1
Overview
This
section
is
non-normative.
This
Section
specifies
the
Hypothetical
Render
Model
illustrated
in
Figure
3
.
The
purpose
of
the
model
is
to
limit
Document
Instance
complexity.
It
is
not
intended
as
a
specification
of
the
processing
requirements
for
implementations.
For
instance,
while
the
model
defines
a
glyph
buffer
for
the
purpose
of
limiting
the
number
of
glyphs
displayed
at
any
given
point
in
time,
it
neither
requires
the
implementation
of
such
a
buffer,
nor
models
the
sub-pixel
character
positioning
and
anti-aliased
glyph
rendering
that
can
be
used
to
produce
text
output.
The
model
specifies
an
(hypothetical)
time
required
for
completely
painting
an
intermediate
synchronic
document
as
a
proxy
for
complexity.
Painting
includes
drawing
region
backgrounds,
rendering
and
copying
glyphs,
and
decoding
and
copying
images.
Complexity
is
then
limited
by
requiring
that
painting
of
intermediate
synchronic
document
E
n
completes
before
the
end
of
intermediate
synchronic
document
E
n-1
.
Whenever
applicable,
constraints
are
specified
relative
to
Root
Container
Region
dimensions,
allowing
subtitle
sequences
to
be
authored
independently
of
Related
Video
Object
resolution.
To
enable
scenarios
where
the
same
glyphs
are
used
in
multiple
successive
intermediate
synchronic
documents
,
e.g.
to
convey
a
CEA-608/708-style
roll-up
(see
[
CEA-608
]
and
[
CEA-708
]),
the
Glyph
Buffers
G
n
and
G
n-1
store
rendered
glyphs
across
intermediate
synchronic
documents
,
allowing
glyphs
to
be
copied
into
the
Presentation
Buffer
instead
of
rendered,
a
more
costly
operation.
Similarly,
Decoded
Image
Buffers
D
n
and
D
n-1
store
decoded
images
across
intermediate
synchronic
documents
,
allowing
images
to
be
copied
into
the
Presentation
Buffer
instead
of
decoded.
11.2
General
The
Presentation
Compositor
SHALL
render
in
Presentation
Buffer
P
n
each
successive
intermediate
synchronic
document
E
n
using
the
following
steps
in
order:
clear
the
pixels,
except
for
the
first
intermediate
synchronic
document
E
0
for
the
which
the
pixels
of
P
0
SHALL
be
assumed
to
have
been
cleared;
paint,
according
to
stacking
order,
all
background
pixels
for
each
region;
paint
all
pixels
for
background
colors
associated
with
text
or
image
subtitle
content;
and
paint
the
text
or
image
subtitle
content.
The
Presentation
Compositor
SHALL
start
rendering
E
n
:
at
the
presentation
time
of
E
0
minus
Initial
Painting
Delay
(IPD),
if
n
=
0;
or
DUR
I
(E
n
)
is
the
duration,
in
seconds,
for
painting
the
image
subtitle
content
for
intermediate
synchronic
document
E
n
,
as
specified
in
Section
.
The
contents
of
the
Presentation
Buffer
P
n
SHALL
be
transferred
instantaneously
to
Presentation
Buffer
P
n-1
at
the
presentation
time
of
intermediate
synchronic
document
E
n
,
making
the
latter
available
for
display.
Note
It
is
possible
for
the
contents
of
Presentation
Buffer
P
n-1
to
never
be
displayed.
This
can
happen
if
Presentation
Buffer
P
n
is
copied
twice
to
Presentation
Buffer
P
n-1
between
two
consecutive
video
frame
boundaries
of
the
Related
Video
Object
.
It
SHALL
be
an
error
for
the
Presentation
Compositor
to
fail
to
complete
painting
pixels
for
E
n
before
the
presentation
time
of
E
n
.
BDraw
effectively
sets
a
limit
on
fillings
regions
-
for
example,
assuming
that
the
Root
Container
Region
is
ultimately
rendered
at
1920×1080
resolution,
a
BDraw
of
12
s
-1
would
correspond
to
a
fill
rate
of
1920×1080×12/s=23.7×2
20
pixels
s
-1
.
NBG(R
i
)
SHALL
be
the
total
number
of
tts:backgroundColor
attributes
associated
with
the
given
region
R
i
in
the
intermediate
synchronic
document
.
A
tts:backgroundColor
attribute
is
associated
with
a
region
when
it
is
explicitly
specified
(either
as
an
attribute
in
the
element,
or
by
reference
to
a
declared
style)
in
the
following
circumstances:
it
is
specified
on
the
region
layout
element
that
defines
the
region;
or
it
is
specified
on
a
div
,
p
,
span
or
br
content
element
that
is
to
be
flowed
into
the
region
for
presentation
in
the
intermediate
synchronic
document
(see
[
ttml2
]
for
more
details
on
when
a
content
element
is
followed
into
a
region);
or
it
is
specified
on
a
set
animation
element
that
is
to
be
applied
to
content
elements
that
are
to
be
flowed
into
the
region
for
presentation
in
the
intermediate
synchronic
document
(see
[
ttml2
]
for
more
details
on
when
a
set
animation
element
is
applied
to
content
elements).
Even
if
a
specified
tts:backgroundColor
is
the
same
as
specified
on
the
nearest
ancestor
content
element
or
animation
element,
specifying
any
tts:backgroundColor
SHALL
require
an
additional
fill
operation
for
all
region
pixels.
11.4
Paint
Images
The
Presentation
Compositor
SHALL
paint
into
the
Presentation
Buffer
P
n
all
visible
pixels
of
presented
images
of
intermediate
synchronic
document
E
n
.
For
each
presented
image
,
the
Presentation
Compositor
SHALL
either:
if
an
identical
image
is
present
in
Decoded
Image
Buffer
D
n
,
copy
the
image
from
Decoded
Image
Buffer
D
n
to
the
Presentation
Buffer
P
n
using
the
Image
Copier;
or
if
an
identical
image
is
present
in
Decoded
Image
Buffer
D
n-1
,
i.e.
an
identical
image
was
present
in
intermediate
synchronic
document
E
n-1
,
copy
using
the
Image
Copier
the
image
from
Decoded
Image
Buffer
D
n-1
to
both
the
Decoded
Image
Buffer
D
n
and
the
Presentation
Buffer
P
n
;
or
otherwise,
decode
the
image
using
the
Image
Decoder
the
image
into
the
Presentation
Buffer
P
n
and
Decoded
Image
Buffer
D
n
.
Two
images
SHALL
be
identical
if
and
only
if
they
reference
the
same
encoded
image
source.
The
duration
DUR
I
(E
n
)
for
painting
images
of
an
intermediate
synchronic
document
E
n
in
the
Presentation
Buffer
SHALL
be
as
follows:
DUR
I
(E
n
)
=
∑
I
i
∈
I
c
NRGA(I
i
)
/
ICpy
+
∑
I
j
∈
I
d
NSIZ(I
j
)
/
IDec
The
contents
of
the
Decoded
Image
Buffer
D
n
SHALL
be
transferred
instantaneously
to
Decoded
Image
Buffer
D
n-1
at
the
presentation
time
of
intermediate
synchronic
document
E
n
.
The
total
size
occupied
by
images
stored
in
Decoded
Image
Buffers
D
n
or
D
n-1
SHALL
be
the
sum
of
their
Normalized
Image
Area.
The
size
of
Decoded
Image
Buffers
D
n
or
D
n-1
SHALL
be
the
Normalized
Decoded
Image
Buffer
Size
(NDIBS).
Unless
specified
otherwise,
the
following
table
SHALL
specify
ICpy,
IDec,
and
NDBIS.
Parameter
Initial
value
Normalized
image
copy
performance
factor
(ICpy)
6
Image
Decoding
rate
(IDec)
1
×
2
20
pixels
s
-1
Normalized
Decoded
Image
Buffer
Size
(NDIBS)
0.9885
11.5
Paint
Text
In
the
context
of
this
section,
a
glyph
is
a
tuple
consisting
of
(i)
one
character
and
(ii)
the
computed
values
of
the
following
style
properties:
tts:color
tts:fontFamily
tts:fontSize
tts:fontStyle
tts:fontWeight
tts:textDecoration
tts:textOutline
tts:textShadow
Note
While
one-to-one
mapping
between
characters
and
typographical
glyphs
is
generally
the
rule
in
some
scripts,
e.g.
latin
script,
it
is
the
exception
in
others.
For
instance,
in
arabic
script,
a
character
can
yield
multiple
glyphs
depending
on
its
position
in
a
word.
The
Hypothetical
Render
Model
always
assumes
a
one-to-one
mapping,
but
reduces
the
performance
of
the
glyph
buffer
for
scripts
where
one-to-one
mapping
is
not
the
general
rule
(see
GCpy
below).
if
an
identical
glyph
is
present
in
Glyph
Buffer
G
n
,
copy
the
glyph
from
Glyph
Buffer
G
n
to
the
Presentation
Buffer
P
n
using
the
Glyph
Copier;
or
if
an
identical
glyph
is
present
in
Glyph
Buffer
G
n-1
,
i.e.
an
identical
glyph
was
present
in
intermediate
synchronic
document
E
n-1
,
copy
using
the
Glyph
Copier
the
glyph
from
Glyph
Buffer
G
n-1
to
both
the
Glyph
Buffer
G
n
and
the
Presentation
Buffer
P
n
;
or
otherwise
render
using
the
Glyph
Renderer
the
glyph
into
the
Presentation
Buffer
P
n
and
Glyph
Buffer
G
n
.
NRGA(G
i
)
does
not
take
into
account
decorations
(e.g.
underline),
effects
(e.g.
outline)
or
actual
typographical
glyph
aspect
ratio.
An
implementation
can
determine
an
actual
buffer
size
needs
based
on
worst-case
glyph
size
complexity.
The
contents
of
the
Glyph
Buffer
G
n
SHALL
be
copied
instantaneously
to
Glyph
Buffer
G
n-1
at
the
presentation
time
of
intermediate
synchronic
document
E
n
.
It
SHALL
be
an
error
for
the
sum
of
NRGA(g
i
)
over
all
glyphs
Glyph
Buffer
G
n
to
be
larger
than
the
Normalized
Glyph
Buffer
Size
(NGBS).
Unless
specified
otherwise,
the
following
table
specifies
values
of
GCpy,
Ren
and
NGBS.
Normalized
glyph
copy
performance
factor
(GCpy)
Script
property
(see
Standard
Annex
#24
at
[
UNICODE
])
for
the
character
of
g
i
GCpy
latin,
greek,
cyrillic,
hebrew
or
base
12
any
other
value
3
Text
rendering
performance
factor
Ren(G
i
)
Block
property
(see
[
UNICODE
])
for
the
character
of
g
i
Ren(G
i
)
CJK
Unified
Ideograph
0.6
any
other
value
1.2
Normalized
Glyph
Buffer
Size
(NGBS)
1
Note
The
choice
of
font
by
the
presentation
processor
can
increase
rendering
complexity.
For
instance,
a
cursive
font
can
generally
result
in
a
given
character
yielding
different
typographical
glyphs
depending
on
context,
even
if
latin
script
is
used.
While
a
Processor
is
required
to
accept,
and
encouraged
to
render,
all
Character
Information
Items
,
practical
considerations
can
result
in
a
Processor
being
capable
of
rendering
only
a
subset
of
them.
In
order
to
increase
the
confidence
that
text
will
be
presented
correctly
by
Processors
targeting
specific
languages,
this
section
defines
common
character
sets
that
authors
are
encouraged
to
use.
Note
The
common
character
sets
defined
herein
are
expected
to
evolve
over
time,
and
implementers
are
encouraged
to
review
them
regularly.
Note
The
definition
of
common
character
sets
herein
is
in
no
way
intended
to
limit
the
set
of
characters
that
a
Processor
renders.
Note
Implementers
are
cautioned
that
a
given
sequence
of
characters
can
yield
different
visual
representations
depending
on
the
context,
including
surrounding
characters,
language
and
font.
In
other
words,
there
is
not
necessarily
a
one-to-one
mapping
between
a
character
and
its
visual
representation.
For
a
given
language
indicated
using
the
xml:lang
attribute,
the
common
character
set
is
equal
to
the
union
of
the
following
sets:
the
main
exemplar
character
set
specified
for
the
language
in
[
CLDR
]
as
well
as
any
corresponding
uppercase
characters
as
specified
in
[
UNICODE
];
and
the
punctuation
exemplar
character
set
specified
for
the
language
in
[
CLDR
];
the
digits
and
symbols
included
in
all
numberSystems
specified
for
the
language
in
[
CLDR
];
the
base
character
set
specified
in
Table
1;
and
supplementary
characters
specified
for
the
language
in
Table
2,
if
any.
Some
of
the
sets
above
can
overlap.
Table
1
captures
the
set
of
characters
intended
to
be
always
available
to
authors.
The
terms
used
in
the
table
are
defined
in
[
UNICODE
].
Table
1.
Base
Character
Set.
(Basic
Latin)
U+0020
-
U+007E
(Latin-1
Supplement)
U+00A0
-
U+00FF
(Latin
Extended-A)
U+0152
:
LATIN
CAPITAL
LIGATURE
OE
U+0153
:
LATIN
SMALL
LIGATURE
OE
U+0160
:
LATIN
CAPITAL
LETTER
S
WITH
CARON
U+0161
:
LATIN
SMALL
LETTER
S
WITH
CARON
U+0178
:
LATIN
CAPITAL
LETTER
Y
WITH
DIAERESIS
U+017D
:
LATIN
CAPITAL
LETTER
Z
WITH
CARON
U+017E
:
LATIN
SMALL
LETTER
Z
WITH
CARON
(Latin
Extended-B)
U+0192
:
LATIN
SMALL
LETTER
F
WITH
HOOK
(Spacing
Modifier
Letters)
U+02DC
:
SMALL
TILDE
(Combining
Diacritical
Marks)
U+0301
:
COMBINING
ACUTE
ACCENT
(General
Punctuation)
U+2010
-
U+2015
:
Dashes
U+2016
-
U+2027
:
General
punctuation
U+2030
-
U+203A
:
General
punctuation
(Currency
symbols)
U+20AC
:
EURO
SIGN
(Letterlike
Symbols)
U+2103
:
DEGREES
CELSIUS
U+2109
:
DEGREES
FAHRENHEIT
U+2120
:
SERVICE
MARK
SIGN
U+2122
:
TRADE
MARK
SIGN
(Number
Forms)
U+2153
-
U+215F
:
Fractions
(Mathematical
Operators)
U+2212
:
MINUS
SIGN
U+221E
:
INFINITY
(Box
Drawing)
U+2500
:
BOX
DRAWINGS
LIGHT
HORIZONTAL
U+2502
:
BOX
DRAWINGS
LIGHT
VERTICAL
U+250C
:
BOX
DRAWINGS
LIGHT
DOWN
AND
RIGHT
U+2510
:
BOX
DRAWINGS
LIGHT
DOWN
AND
LEFT
U+2514
:
BOX
DRAWINGS
LIGHT
UP
AND
RIGHT
U+2518
:
BOX
DRAWINGS
LIGHT
UP
AND
LEFT
(Block
Elements)
U+2588
:
FULL
BLOCK
(Geometric
Shapes)
U+25A1
:
WHITE
SQUARE
(Musical
Symbols)
U+2669
:
QUARTER
NOTE
U+266A
:
EIGHTH
NOTE
U+266B
:
BEAMED
EIGHTH
NOTES
Table
2
specifies
supplementary
character
set
that
have
proven
useful
in
captioning
and
subtitling
applications
for
a
number
of
selected
languages.
Table
2
is
non-exhaustive,
and
will
be
extended
as
needs
arise.
Figure
5
below
illustrates
the
use
of
forced
content,
i.e.
itts:forcedDisplay
and
displayForcedOnlyMode
.
The
content
with
itts:forcedDisplay="true"
is
the
French
translation
of
the
"High
School"
sign.
The
content
with
itts:forcedDisplay="false"
are
French
subtitles
capturing
a
voiceover.
Figure
5
Illustration
of
the
use
of
itts:forcedDisplay
When
the
user
selects
French
as
the
playback
language
but
does
not
select
French
subtitles,
displayForcedOnlyMode
is
set
to
"true"
,
causing
the
display
of
the
sign
translation,
which
is
useful
to
any
French
speaker,
but
hiding
the
voiceover
subtitles
as
the
voiceover
is
heard
in
French.
If
the
user
selects
French
as
the
playback
language
and
also
selects
French
subtitles,
e.g.
if
the
user
is
hard-of-hearing,
displayForcedOnlyMode
is
set
to
"false"
,
causing
the
display
of
both
the
sign
translation
and
the
voiceover
subtitles.
The
algorithm
for
setting
the
displayForcedOnlyMode
parameter
and
selecting
the
appropriate
combination
of
subtitle
and
audio
tracks
depends
on
the
application.
Thus,
for
each
subtitle
in
an
Image
Profile
Document
Instance
,
text
alternative
content
in
a
Text
Profile
Document
Instance
SHOULD
be
written
so
that
it
conveys
all
essential
content
and
fulfills
the
same
function
as
the
corresponding
subtitle
image.
In
the
context
of
subtitling
and
captioning,
this
content
will
be
(as
a
minimum)
the
verbatim
equivalent
of
the
image
without
précis
or
summarization.
However,
the
author
MAY
include
extra
information
to
the
text
alternative
in
cases
where
styling
is
applied
to
the
text
image
with
a
deliberate
connotation,
as
a
functional
replacement
for
the
applied
style.
During
authoring,
the
altText
named
metadata
item
can
be
used
to
associate
a
simple
text
string
with
an
image
to,
for
example:
Success
Criterion
1.4.3
at
[
WCAG21
]
specifies
that,
with
some
exceptions,
the
visual
presentation
of
text
and
images
of
text
has
a
contrast
ratio
of
at
least
4.5:1.
In
the
context
of
Text
Profile
,
this
is
achieved
by
specifying
appropriate
foreground
and
background
colors.
D.1.3
Success
Criterion
1.4.12
Text
Spacing
Success
Criterion
1.4.12
at
[
WCAG21
]
specifies
that
no
loss
of
content
or
functionality
occur
when
spacing
of
lines,
letters,
words
and
paragraphs
is
modified
by
a
specified
amount.
In
the
context
of
this
specification,
this
is
achieved
by
specifying
an
appropriate
combination
of
style
properties
to
achieve
the
desired
line
height,
font
size,
region
extent,
etc.
D.1.4
Success
Criteria
3.1.1
Language
of
Page
and
3.1.2
Language
of
Parts
Success
Criteria
3.1.1
and
3.1.2
at
[
WCAG21
]
specify
that
the
human
language
of
each
passage
or
phrase
in
the
content
can
be
programmatically
determined.
In
the
context
of
this
specification,
this
is
achieved
by
specifying
xml:lang
.
D.2
MAUR
Considerations
This
section
is
non-normative.
Authors
and
implementers
are
encouraged
to
consult
[
media-accessibility-reqs
],
which
presents
accessibility
requirements
users
with
disabilities
have
with
respect
to
audio
and
video
on
the
web.
Note
E.
Sample
Document
Instance
This
section
is
non-normative.
The
following
sample
Document
Instances
conforms
to
the
Text
Profile
and
Image
Profile
,
respectively.
These
samples
are
for
illustration
only,
and
are
neither
intended
to
capture
current
or
future
practice,
nor
exercise
all
normative
prose
contained
in
this
specification.
The
following
sections
define
extension
designations,
expressed
as
relative
URIs
(fragment
identifiers)
relative
to
the
IMSC
Extension
Namespace
base
URI.
F.2
#progressivelyDecodable
The
#progressivelyDecodable
feature
is
designated
as
permitted-deprecated
in
the
profiles
defined
by
this
specification.
The
#aspectRatio
feature
is
designated
as
permitted-deprecated
in
the
profiles
defined
by
this
specification.
The
#displayAspectRatio
feature
provides
equivalent
semantics.
The
#altText
feature
is
designated
as
permitted-deprecated
in
the
profiles
defined
by
this
specification.
The
altText
named
metadata
item
provides
equivalent
semantics.
A
transformation
processor
supports
the
#linePadding
feature
if
it
recognizes
and
is
capable
of
transforming
values
of
the
ebutts:linePadding
attribute
specified
in
[
EBU-TT-D
].
A
presentation
processor
supports
the
#linePadding
feature
if
it
implements
presentation
semantic
support
for
values
of
the
ebutts:linePadding
attribute
specified
in
[
EBU-TT-D
].
F.7
#multiRowAlign
A
transformation
processor
supports
the
#multiRowAlign
feature
if
it
recognizes
and
is
capable
of
transforming
values
of
the
ebutts:multiRowAlign
attribute
specified
in
[
EBU-TT-D
].
A
presentation
processor
supports
the
#multiRowAlign
feature
if
it
implements
presentation
semantic
support
for
values
of
the
ebutts:multiRowAlign
attribute
specified
in
[
EBU-TT-D
].
XML
Schema
definitions
(see
[
xmlschema-1
])
for
extension
vocabulary
defined
by
this
specification
are
provided
here
for
convenience.
These
definitions
are
non-normative
and
are
not
sufficient
to
validate
conformance
of
a
Document
Instance
.
In
any
case
where
a
definition
specified
by
this
appendix
diverge
from
the
prose
of
the
specification,
then
the
latter
takes
precedence.
H.
Extensibility
Objectives
This
section
is
non-normative.
This
section
documents
extensibility
objectives
for
this
specification.
This
specification
is
intended
to
allow:
other
profiles
of
TTML
and
future
revisions
of
this
specification
to
specify
support
for
documents
and/or
processors
conforming
to
Text
Profile
or
Image
Profile
,
in
addition
to
specifying
additional
extensions;
I.
Compatibility
with
other
TTML-based
specifications
This
section
is
non-normative.
I.1
Overview
This
specification
is
designed
to
be
compatible
with
[
ttml-imsc1
],
[
ttml-imsc1.0.1
],
[
SMPTE2052-1
],
[
EBU-TT-D
]
and
[
ttml10-sdp-us
].
Specifically,
by
selecting
a
subset
of
the
features
and
extensions
defined
in
this
specification,
it
is
possible
to
create
a
document
that:
This
specification
is
also
intended
to
allow
straightforward
conversion
of
a
document
that
conforms
to
the
text
or
image
profiles
of
[
CFF
]
to
the
Text
Profile
or
Image
Profile
,
respectively.
The
profile
vocabulary
defined
in
[
ttml2
]
is
prohibited
by
[
EBU-TT-D
].
Instead,
as
specified
in
[
EBU-TT-M
],
multiple
ebuttm:conformsToStandard
elements
are
optionally
present
in
the
metadata
element
of
the
head
element,
with
each
ebuttm:conformsToStandard
indicating
conformance
to
a
specification,
including
other
versions
of
this
specification.
Note
Conformance
to
a
[
ttml-imsc1.0.1
]
profile
can
be
indicated
as
defined
in
[
ttml-imsc1.0.1
],
by
including
an
additional
ebuttm:conformsToStandard
element
whose
value
is
equal
to
the
designator
of
the
[
ttml-imsc1.0.1
]
profile
to
which
the
Document
Instance
conforms.
It
is
not
possible
for
a
document
that
conforms
to
[
EBU-TT-D
]
to
also
conform
to
Image
Profile
,
and
vice-versa,
notwithstanding
the
special
case
where
the
document
also
conforms
to
Text
Profile
as
noted
at
§
6.
Profiles
.
The
following
is
an
example
of
a
document
that
conforms
to
Text
Profile
,
[
ttml-imsc1.0.1
]
Text
Profile
and
[
EBU-TT-D
].
Note
the
presence
of
multiple
ebuttm:conformsToStandard
elements,
one
of
which
equals
the
Text
Profile
designator:
[
SMPTE2052-1
]
specifies
the
use
of
the
DFXP
Full
Profile
(see
Appendix
F.3
at
[
ttml2
])
supplemented
by
a
number
of
extensions,
including
http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt#image
.
This
specification
defines
practical
constraints
on
[
SMPTE2052-1
],
supplemented
by
extensions
defined
herein
and
selected
[
ttml2
]
features.
These
constraints
and
extensions
are
intended
to
reflect
industry
practice.
As
a
result,
particular
care
is
required
when
creating
a
document
intended
to
be
processed
according
to
[
SMPTE2052-1
],
and
Text
Profile
or
Image
Profile
.
In
particular:
<?xml version="1.0" encoding="UTF-8"?><ttxml:lang="en"xmlns="http://www.w3.org/ns/ttml"xmlns:ttm="http://www.w3.org/ns/ttml#metadata"xmlns:ttp="http://www.w3.org/ns/ttml#parameter"ttp:profile="http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full"xmlns:tts="http://www.w3.org/ns/ttml#styling"ttp:frameRate="24"><head><layout><regionxml:id="area1"tts:origin="10% 70%"tts:extent="80% 20%"tts:showBackground="whenActive"tts:backgroundColor="red"tts:displayAlign="center"tts:color="white"/></layout></head><bodytts:lineHeight="100%"><div><pregion="area1"begin="00:00:01.01"end="00:00:03">This should appear on frame 25.</p><pregion="area1"begin="00:00:04"end="00:00:06">This should appear on frame 96.</p><pregion="area1"begin="00:00:07.33"end="00:00:09">This should appear on frame 176.</p></div></body>
</
tt
>
I.5
CFF-TT
This
specification
was
derived
from
the
text
and
image
profiles
specified
in
Section
6
at
[
CFF
],
and
is
intended
to
be
a
superset
in
terms
of
capabilities.
Additional
processing
is
however
generally
necessary
to
convert
a
document
from
[
CFF
]
to
this
specification.
In
particular:
the
namespace
of
the
progressivelyDecodable
attribute
is
different;
the
forcedDisplayMode
attribute
in
[
CFF
]
is
renamed
to
forcedDisplay
in
this
specification;
the
[
CFF
]
HRM
does
not
specify
GCpy
as
a
function
of
script;
in
[
CFF
],
the
attribute
ttp:frameRate
is
not
subject
to
the
requirements
specified
at
Section
§
8.12.7
#frameRate
;
and
[
CFF
]
mandates
a
value
for
the
use
attribute
of
the
ttp:profile
.
This
value
signals
a
processor
profile
that
is
not
compatible
with
the
processor
profiles
specified
in
this
specification.
A
number
of
features
that
were
previously
permitted
in
previous
versions
of
IMSC
are
designated
as
permitted-deprecated
in
the
Text
Profile
and
Image
Profile
.
Documents
that
use
such
features
are
therefore
susceptible
to
being
incompatible
with
future
versions
of
this
specification.
The
editor
acknowledges
the
current
and
former
members
of
the
Timed
Text
Working
Group,
the
members
of
other
W3C
Working
Groups,
and
industry
experts
in
other
forums
who
have
contributed
directly
or
indirectly
to
the
process
or
content
of
this
document.
The
editor
wishes
to
especially
acknowledge
the
following
contributions
by
members:
Glenn
Adams,
Skynav;
John
Birch,
Invited
expert;
Mike
Dolan,
Invited
expert;
Nigel
Megitt,
British
Broadcasting
Corporation;
Thierry
Michel,
W3C
;
Andreas
Tai,
Institut
für
Rundfunktechnik;
Stefan
Pöschel,
Institut
für
Rundfunktechnik.
The
editor
also
wishes
to
acknowledge
Digital
Entertainment
Content
Ecosystem
(DECE)
for
contributing
to
the
initial
document
for
the
Member
Submission.
K.
Privacy
and
Security
Considerations
This
section
is
non-normative.
With
the
exception
of
the
following,
the
security
and
privacy
considerations
of
[
ttml2
]
apply:
Appendix
P.7
(Access
to
Processing
State),
since
the
condition
attribute
is
not
supported.
Editor's
note
L.
Summary
of
substantive
changes
This
section
is
non-normative.
L.1
Overview
This
appendix
summarizes
changes
made
from
[
ttml-imsc1.1
].
