IRC log of tt on 2015-04-09

Timestamps are in UTC.

15:43:15 [RRSAgent]
RRSAgent has joined #tt
15:43:15 [RRSAgent]
logging to
15:43:17 [trackbot]
RRSAgent, make logs public
15:43:17 [Zakim]
Zakim has joined #tt
15:43:19 [trackbot]
Zakim, this will be TTML
15:43:19 [Zakim]
ok, trackbot; I see SYMM_TTWG()10:00AM scheduled to start 103 minutes ago
15:43:20 [trackbot]
Meeting: Timed Text Working Group Teleconference
15:43:20 [trackbot]
Date: 09 April 2015
15:43:42 [nigel]
Present: glenn, nigel, atai2
15:43:44 [nigel]
chair: nigel
15:43:48 [nigel]
scribe: nigel
15:57:28 [nigel]
Present+ pal, dae_kim
16:03:17 [nigel]
Present+ tmichel
16:21:59 [nigel]
Topic: Agenda for this meeting
16:22:35 [nigel]
Present+ Courtney
16:23:05 [glenn]
glenn has joined #tt
16:34:06 [nigel]
group: Introductions
16:34:16 [nigel]
tmichel: Thierry Michel, staff contact W3C
16:34:22 [nigel]
nigel: Nigel Megitt, BBC, chairing
16:35:05 [nigel]
glenn: Glenn Adams, Skynav, Editor TTML
16:35:39 [nigel]
dae_kim: Dae Kim, Netflix, observing
16:36:36 [nigel]
atai2: Andreas Tai, IRT
16:36:44 [dakim]
dakim has joined #tt
16:37:04 [nigel]
pal: Pierre Lemieux, Movielabs
16:37:14 [nigel]
courtney: Courtney Kennedy, Apple
16:37:21 [nigel]
16:37:28 [nigel]
16:37:46 [dakim]
Dae Kim, Netflix
16:37:54 [nigel]
nigel: Runs through planned agenda; topics and agenda.
16:38:04 [tai]
tai has joined #tt
16:38:10 [nigel]
pal: I have some comments to raise on TTML2 that I think overlap with the existing topic list
16:38:26 [nigel]
Courtney: I'd like to raise future work in WebVTT specifically Japanese script display
16:38:47 [nigel]
nigel: I propose spending day 1 on TTML2 and day 2 on IMSC 1 and WebVTT and future stuff,
16:38:59 [nigel]
... with some time at the end to revisit any topics that we want to.
16:39:02 [courtney]
courtney has joined #tt
16:39:04 [nigel]
group: Happy with that.
16:39:07 [nigel]
nigel: AOB?
16:39:12 [nigel]
group: No AOB
16:39:37 [nigel]
Topic: TTML2
16:42:26 [nigel]
nigel: Actions - there's nothing to discuss here
16:44:07 [nigel]
nigel: Issues - there's no work on open TTML2 issues since the last meeting
16:44:24 [nigel]
glenn: In the TTML2 ED there are Editorial Notes, Issues and "to be defined" things listed.
16:44:42 [nigel]
... I've put them into a spreadsheet and classified them as Editorial (no technical thought needed),
16:45:07 [nigel]
... Technical (requires technical effort) and "X" (needs example materials). There are 105 items
16:45:10 [nigel]
... in the spreadsheet.
16:45:48 [nigel]
... Out of those 105 around 2/3 are Technical, and 1/3 are mostly examples with a few pure editorial things
16:46:13 [nigel]
... This is forming my task list
16:47:35 [dakim]
dakim has joined #tt
16:50:35 [glenn]
16:50:55 [tmichel]
tmichel has joined #tt
16:55:01 [nigel]
nigel: I suggest we go through the TTML2 change topics and call out these spreadsheet changes
16:55:04 [nigel]
... where needed.
16:57:20 [nigel]
nigel: First topic is profiles - especially to support the registry of TTML flavours
16:57:50 [nigel]
glenn: There are some changes here in §5.2, §6 and Appendix D
16:58:05 [nigel]
glenn: There are two issues Issue-351 and Issue-352
16:58:08 [nigel]
16:58:08 [trackbot]
issue-351 -- Update IANA registration for TTML2 -- open
16:58:08 [trackbot]
16:58:11 [nigel]
16:58:11 [trackbot]
issue-352 -- Add Media Registration Annex -- open
16:58:11 [trackbot]
16:58:39 [nigel]
glenn: The first of those listed is to restore and update the Media Type Registration
16:59:12 [nigel]
... That was Issue-352. The second is Issue-351, which is to define the syntax for processor profiles
16:59:54 [nigel]
glenn: I don't believe there's anything needed for discussion here. I think we've done that.
17:01:43 [glenn]
17:01:43 [nigel]
... Syntax could be something to discuss
17:02:29 [nigel]
glenn: You can express with this simplified syntax what can also be expressed in the profiles
17:02:33 [nigel]
... mechanism that's in TTML2
17:03:05 [nigel]
... Stepping back a little, I want to check that we have an understanding tha this parameter is
17:03:22 [nigel]
... specifying what processor is required in the mind of the author to be able to process this document
17:03:43 [nigel]
... as opposed to making a declaration about the content profile that is followed. Is that a shared understanding?
17:04:11 [nigel]
... The content profile states what features have been used whereas the processor profile can be potentially
17:04:23 [nigel]
... inferred from the content profile, and says 'this is what I need the processor to be able to support'.
17:04:35 [nigel]
tai: They're not the same.
17:04:50 [nigel]
glenn: No, you might say that a processor that is a superset or even a subset is adequate.
17:05:07 [nigel]
tai: From a different perspective, people approached EBU and TTWG with a requirement to distinguish the
17:05:28 [nigel]
... different documents with respect to which specifications the document conforms to, and want a mechanism
17:05:45 [nigel]
... to describe this. I saw this more as a content profile not a list of processor requirements. More to say "this
17:05:57 [nigel]
... document I guarantee conforms to SDP-US, IMSC or whatever"
17:06:14 [nigel]
glenn: That's orthogonal to what the processor needs to support. The only reason I can see for declaring a
17:07:09 [nigel]
... content profile is for validation processing. For non-validating processors it's therefore not relevant. THe
17:07:26 [nigel]
... only potential relevance is to infer a processor profile from it. If a document only has a content profile
17:07:47 [nigel]
... declaration but no processor profile declaration then it's possible to infer a maximal processor profile.
17:10:38 [nigel]
nigel: My recollection from the previous discussion is that the main use case is for MPEG-4 signalling of what
17:10:53 [nigel]
... processor is needed, which I think came from David Singer.
17:11:05 [nigel]
tai: Will this also work for TTML1 derivatives too?
17:12:23 [nigel]
glenn: The higher level syntax to allow operators and combinations, but if you ignore that and make it a simple token value
17:13:03 [nigel]
... e.g. "stpp.C", when we discussed this codecs registry what we said is that it would be a mapping from a set
17:13:23 [nigel]
... of small identifiers to their corresponding designators that are externally defined. I had seeded the table
17:13:41 [nigel]
... on the wiki page with the original TTML1 profiles and the SDP-US profile. The identifier in the left column
17:14:03 [nigel]
... was the short value in place of e.g. "C" above it could be "tt1p". Notice I included the version number in the
17:14:27 [nigel]
... short identifiers. So if you want an implementation that at least supports the original TTML1 profile as
17:14:44 [nigel]
... originally defined then you could use the short code in there. What we haven't done yet is to add the new
17:15:05 [nigel]
... TTML2 profiles, which there are 3 of, and we haven't added any industry profiles like EBU-TT-D etc.
17:15:29 [nigel]
... All of these profiles do go back to TTML1 so from that perspective this solution will be valid.
17:15:33 [nigel]
tai: When can this be used?
17:16:09 [nigel]
glenn: The only thing we need to update in the registration is the extra parameter.
17:16:53 [nigel]
tai: What we need to be able to say is when people can use this.
17:17:15 [nigel]
glenn: The syntactic aspect of it is something that has to involve IANA. The values used within it can be
17:17:34 [nigel]
... offloaded to the registry on our wiki.
17:18:01 [nigel]
... It's somewhat complicated by the optional parameter in the original registration of "profile"
17:18:59 [nigel]
... We used the term "document profile" to mean processor profile, which is confusing.
17:19:27 [nigel]
... ttp:profile takes as its argument an xs:anyURI value that can be relative or absolute.
17:20:24 [nigel]
... There are two things that are different in the new proposal. 1) The syntax and 2) to use short codes not URIs
17:20:39 [nigel]
... This allows for shorter labels and a public registry for people to register mappings between identifiers and
17:21:00 [nigel]
... URIs, and therefore to make known publicly specifications of profiles.
17:21:13 [nigel]
tai: So the ttp:profile could be used already?
17:21:27 [nigel]
glenn: Right, and it needs to match the URI syntax of ttp:profile.
17:21:42 [nigel]
tai: To use this existing profile, that's a debate that's been used several times in the past. Do you need a
17:21:54 [nigel]
... complete profile document or...
17:21:59 [nigel]
glenn: It can be prose only.
17:22:06 [nigel]
tai: So we can use this mechanism already?
17:22:47 [nigel]
glenn: That's correct. In TTML1 it may be "any URI that feasibly dereferences a profile definition document."
17:23:05 [nigel]
... That means its potential but not necessarily. Also that document can have no content other than its URI.
17:23:21 [nigel]
... It could be a one line profile that is a formal profile definition document with no child elements that refer
17:23:34 [nigel]
... to any features. All of the definition could be in prose in that document. In that sense it's just a pointer.
17:23:50 [nigel]
tai: This is what people are looking for at the moment. We could use it already for EBU-TT-D?
17:24:01 [nigel]
glenn: You could use that today if you don't want to do combination.
17:24:10 [nigel]
tai: And there's no need to register any designator?
17:24:39 [nigel]
glenn: The only requirement is that it doesn't use the TT namespace as a prefix. Other than that it can be any URI.
17:26:16 [nigel]
nigel: Two other requirements that were raised before are to be able to signal multiple processors that can
17:26:23 [nigel]
... process, and also to use short codes.
17:27:05 [nigel]
tai: It's good to know what we can use now.
17:27:22 [nigel]
glenn: You can signal a forward path using the current profile parameter and moving to the new mechanism.
17:27:31 [nigel]
tai: That sounds good.
17:27:52 [nigel]
glenn: There's already a note in TTML1 that says that processors do not need to be able to dereference the URI.
17:29:42 [nigel]
nigel: Stepping in with a bit of chairing, I'm hearing that there's no technical objection, the editorial requirements
17:30:02 [nigel]
... are clear and that there's a forward path for TTML1 profiles. Is that fair?
17:30:06 [nigel]
group: agrees.
17:30:16 [nigel]
nigel: Let's take a short break.
17:30:23 [nigel]
rrsagent, make logs public
17:30:27 [nigel]
rrsagent, draft minutes
17:30:27 [RRSAgent]
I have made the request to generate nigel
17:47:57 [nigel]
Topic: TTML2: timing
17:48:50 [nigel]
nigel: Glenn has a couple of entries in the spreadsheet here.
17:50:11 [nigel]
pal: see my email at
17:51:29 [nigel]
... basically, what is the relationship between the timeings and the media?
17:51:50 [nigel]
glenn: There are lots of issues here! There are lots of potentially different clocks at work.
17:52:02 [nigel]
... Also there may be no related media object.
17:52:11 [dakim]
dakim has joined #tt
17:52:17 [nigel]
pal: Okay let's start with that.
17:52:21 [nigel]
nigel: Media timebase?
17:52:29 [nigel]
pal: Let's start with that as the simplest most common example
17:52:48 [nigel]
glenn: Terminology is an issue here obviously.
17:53:30 [nigel]
nigel: I have quite a clear view of what the current spec means, so I'm interested in exactly what questions arise that are maybe not so clear.
17:54:21 [nigel]
tai: I agree that there are questions that keep arising.
17:54:45 [nigel]
pal: So nigel could you draw a diagram showing the relationship between media offset, root temporal extent, etc.?
17:54:54 [nigel]
nigel: I'd rather not because I object to using mediaOffset!
17:55:00 [nigel]
glenn: That's a separate topic.
17:55:54 [nigel]
... We have made some progress in clarifying what we brought in from SMIL. Appendix M is one such attempt,
17:56:09 [nigel]
... but falls short of nailing down everything. What we need to do is to nail down exactly what you asked in
17:56:34 [nigel]
... your question. Recently I've had questions about the computed body duration vs the implicit body duration.
17:56:55 [nigel]
... Does the computed time become the time of the related media object's duration? If there's no related media
17:57:06 [nigel]
... object is the computed time of the body related solely to the timestamps in the document.
17:57:33 [nigel]
glenn: The reason for mediaOffset in my mind was to address the condition where content is authored for
17:57:52 [nigel]
... arbitrary or dynamic differences between the timeline of the related media object. This comes up with SMPTE
17:58:23 [nigel]
... timeBase especially e.g. should people put begin="0" and offset of 10 hours to get to "10:00:00" as a start
17:58:34 [nigel]
... and there's another example with negative times.
17:58:50 [nigel]
tai: What I think would be helpful would be for readers to have this picture.
17:59:10 [nigel]
... Appendix M is a good start but some images might be helpful.
18:00:14 [Zakim]
Zakim has left #tt
18:10:23 [nigel]
nigel: Draws a picture. Question arises as to the impact/meaning of Root Temporal Extent.
18:12:38 [nigel]
nigel: My interpretation is that the root temporal extent begins at the earliest computed begin time and ends at the
18:12:47 [nigel]
... latest computed end time.
18:13:09 [nigel]
glenn: For media timelines I would begin every root temporal extent at zero [looks at spec] ... but the spec
18:13:19 [nigel]
... has it more like your interpretation nigel.
18:13:47 [courtney]
courtney has joined #tt
18:23:26 [nigel]
pal: The next question is what is the implicit duration?
18:24:06 [nigel]
nigel: I generally don't have a usage for this, but there is a specific case where it comes in. Consider a body
18:24:32 [nigel]
... with a dur attribute but no begin and end attribute, and simple, untimed content. The resolved begin time
18:25:01 [nigel]
... is whenever you make the document active and the resolved end time is that resolved begin time + the dur
18:25:03 [nigel]
... attribute.
18:25:20 [nigel]
glenn: Part of the problem is that we also have to deal with an event based model.
18:25:26 [tmichel]
SMIL Descriptive terms for times
18:26:01 [nigel]
glenn: What's the difference between implicit duration and active duration?
18:28:30 [nigel]
... TTML 1 says that the implicit duration is indefinite, in §10.4, and that's in TTML2 §12.4.
18:28:53 [nigel]
nigel: For me this is a feature of par timeContainers where the begin and end times of a descendant element
18:29:20 [nigel]
... relate to its parent, and that nesting construct applies both to content elements and to TTML documents
18:29:29 [nigel]
... themselves relative to some external playback.
18:31:39 [nigel]
glenn: Under the SMIL 3 timing and synchronisation module there's a table defining the simple duration
18:32:09 [nigel]
... We don't have repeatDur and repeatCount so in TTML they're always unspecified.
18:32:34 [nigel]
... Then there's an algorithm for computing the active duration which defines some maths, and then
18:33:23 [nigel]
... the "active duration algorithm". I've implemented all this in code.
18:33:32 [nigel]
tmichel: Also there are some descriptions in §5.7 of SMIL 3.
18:34:28 [nigel]
pal: It already helps to know that "implicit duration" has a meaning in SMIL. Maybe it's just a matter of
18:34:44 [nigel]
... condensing in one place in the spec exactly how the TTML attributes apply to the SMIL model.
18:35:46 [nigel]
glenn: We originally based the timing syntax and semantics on SMIL taking into account the SMIL specific way
18:36:08 [nigel]
... to include SMIL in other specifications. We overrode some aspects of it. We didn't want text to have an
18:36:24 [nigel]
... implicit duration of zero for example - we made it indefinite so that untimed text expands out to its
18:36:35 [nigel]
... container's duration. That's what TTML1 §10.4 and TTML2 §12.4 do.
18:38:01 [nigel]
glenn: You have to go back to the SMIL timing model to define the timing model as we intended it. If we were
18:38:14 [nigel]
... to pull it out it would take quite a lot of work, i.e. to remove the dependency on SMIL.
18:38:33 [nigel]
tai: It made it difficult for the EBU group for example to look into SMIL, and it's a generally difficult task to
18:39:25 [nigel]
... read and understand SMIL. I think this is a generally difficult topic to understand. It would make it easier if we
18:39:34 [nigel]
... can allow people to understand the timing model without reading SMIL.
18:39:53 [nigel]
glenn: A similar thing arises with formatting semantics - we did the same thing there where we reused XSL.
18:40:33 [nigel]
pal: If the document says "all the semantics of SMIL apply except where specifically stated" and then we
18:40:49 [nigel]
... highlight SMIL terms and where there's a difference then at least it helps a reader to figure out where to look.
18:41:09 [nigel]
... I share the concern that SMIL is difficult to implement and that timing is central to TTML.
18:41:25 [nigel]
glenn: I can't disagree with any of that - people have been put off by SMIL, which is hard to get your head into.
18:42:15 [nigel]
... We did what you suggested part way, e.g. on the definition of begin, end, dur and timeContainer, where
18:42:25 [nigel]
... we say that the semantics are based on SMIL.
18:43:16 [nigel]
pal: Maybe provide a nice diagram like the one Nigel has drawn to show this.
18:44:03 [nigel]
nigel: I don't mind drawing some pictures here, but they should be non-normative.
18:44:23 [nigel]
glenn: We need to consider what is currently broken, e.g. mediaOffset which I thought was needed. Also a
18:44:39 [nigel]
... reader education effort to explain the model in a more accessible way to understand the complexity without
18:44:55 [nigel]
... having to dive into SMIL. The first is necessary for us to get into the spec right away. The second part
18:45:12 [nigel]
... technically doesn't need to be in the spec but if we can make a straightforward improvement in out time
18:45:19 [nigel]
... frame then let's do that.
18:47:03 [nigel]
pal: It would be useful even to clarify the meaning of Root Temporal Extent in terms of SMIL for example.
18:49:07 [nigel]
glenn: If RTE is the difference between the latest and the earliest resolved time coordinate in the document
18:49:18 [nigel]
... then we can state that.
18:49:31 [nigel]
nigel: I don't think that would cause any difference, for RTE = resolved begin -> resolved end
18:49:38 [nigel]
pal: Is that an action to change the spec?
18:49:51 [nigel]
glenn: I would like to have a few diagrams. You can overdo them - the question is what do you want to
18:50:05 [nigel]
... communicate. Since we've been focusing on media timeBase, at a minimum we probably want to have a
18:50:18 [nigel]
... diagram that shows some of this working in the media timeBase. The diagram may look different for other
18:50:20 [nigel]
... timeBases.
18:54:02 [nigel]
nigel: It does, and I can show how. For smpte you have to look for specific timecode values.
18:54:20 [nigel]
glenn and nigel: some discussion about mapping smpte discontinuous into a continuous mode and mapping
18:54:45 [nigel]
... smpte into media; need to be careful in case smpte is being used so the TTML document survives media edits
18:55:10 [nigel]
glenn: If we think we can translate the other timeBases into media then having diagrams for media time
18:55:13 [nigel]
... gives the most value.
18:55:32 [nigel]
tai: The media timebase view would be helpful.
18:55:36 [nigel]
glenn: We don't need it normatively.
18:56:06 [nigel]
tai: Exactly. Also, it helps readers to understand the context operationally, and why different models might be useful.
18:56:19 [nigel]
... If you can do this trick and connect to daily operation then it will be easier for them to understand.
19:02:32 [nigel]
nigel: I'm happy to take an action to create some diagrams, but I'm not sure what the set of concepts is that
19:03:25 [nigel]
... need to define on that picture.
19:04:16 [nigel]
pal: I'd also like to clarify all the SMIL time references.
19:04:34 [nigel]
pal: The example you've drawn is incredibly useful because it helps point to a problem with containers, that
19:05:59 [nigel]
... say "start playback 5 seconds into the media" where the media is TTML with no begin and end values.
19:06:07 [nigel]
... There's an unresolvable infinite loop.
19:06:55 [nigel]
nigel: We can solve that with a normative statement I think. It could be to require a begin attribute on something, for example.
19:07:03 [nigel]
pal: That could help for IMSC 1 for example.
19:07:16 [nigel]
Courtney: It might be a nice simplification.
19:11:03 [nigel]
pal: If a document has a body with no time attributes and a p that begins at 10 hours, and the intention is
19:11:19 [nigel]
... to start playback at the beginning of the media then you'd better have a container that says 'start playing
19:11:24 [nigel]
... 10 hours in'.
19:11:26 [nigel]
nigel: Right.
19:11:40 [nigel]
glenn: That's why I wanted a mediaOffset parameter.
19:11:52 [nigel]
nigel: That's a container issue not something that should be in the TTML, IMO.
19:12:29 [nigel]
pal: It would be useful to clarify that in the media timeBase time 0 always corresponds to the beginning of the
19:12:30 [nigel]
... media.
19:12:58 [nigel]
pal: [draws a typical containment scenario where the media container defines relative offsets between video and TTML]
19:13:26 [nigel]
glenn: In my mind the mediaOffset was metadata to indicate some information in the absence of external
19:13:52 [nigel]
... container information. I would still resolve that example as saying that the document contents begin at
19:14:04 [nigel]
... 10 hours, and the timed text timing model doesn't care about how the synchronisation works.
19:14:28 [nigel]
... If you want to allow negative times and apply some arbitrary time in TTML in addition to the container
19:14:47 [nigel]
... offset then that's another thing.
19:15:03 [nigel]
nigel: I would say that we should not do that. It's actively unhelpful to have this information potentially in two
19:15:05 [nigel]
... places.
19:16:06 [nigel]
pal: The ultimate synchronisation/resolution of the timing is set by the container.
19:16:10 [nigel]
nigel: And that's unavoidable.
19:16:24 [nigel]
pal: Right. It's only when you bring it back in with a container that you can actually combine this stuff.
19:16:45 [nigel]
glenn: So if you had a way to say "in this TTML we think the related media object starts 1 hour in"...
19:17:04 [nigel]
pal: I think that would be ignored.
19:17:27 [nigel]
nigel: You have to think about the encoder/packager.
19:17:35 [nigel]
pal: You could just look at the first time value?
19:17:49 [nigel]
nigel: No, because the intent might deliberately be that the first subtitle begins 5s into the media.
19:17:55 [nigel]
pal: Okay then you do need that.
19:18:20 [nigel]
Courtney: You need this in order to create the container and package it up.
19:18:35 [nigel]
glenn: We could include this as metadata then.
19:18:43 [nigel]
nigel: Yes you could do.
19:18:56 [nigel]
pal: I think that metadata could be useful but you can't normatively apply it because there may be cases where
19:19:16 [nigel]
... after creating the TTML the video is edited or further offset.
19:19:21 [nigel]
nigel: +1
19:19:52 [nigel]
glenn: If you see an arbitrary TTML document and the first resolved begin time is 1 hour in you can't tell if
19:19:56 [nigel]
... that's intentional or not.
19:20:18 [nigel]
nigel: Exactly. It could be the second 1 hour long sample of TTML for a longer thing.
19:20:31 [nigel]
glenn: Yes.
19:20:45 [nigel]
tai: Does this happen in real workflows, that the video is edited or offset?
19:21:05 [nigel]
Courtney: You might have a late delivery scenario where the video sent to the caption author isn't the same
19:21:13 [nigel]
... version as what's played out, exactly.
19:21:24 [nigel]
pal: You can't guarantee that the end point video is exactly the same.
19:21:36 [nigel]
tai: So you have to define in an external context what the offset is.
19:21:45 [nigel]
Courtney: I agree. Whoever is packaging it up has to make those adjustments.
19:23:55 [nigel]
pal: So you might require in a workflow that the relative offset compared to the media originally supplied is
19:23:57 [nigel]
... indicated.
19:24:15 [nigel]
pal: And then you have the other challenge that the package indication of frame rate might differ from what
19:24:38 [nigel]
... was used when the document was authored, e.g. a 23.98 fps video referred to as 24 fps.
19:24:55 [nigel]
nigel: Right, and we resolved that with metadata in EBU-TT-D to indicate exactly that scenario, so that at least
19:25:13 [nigel]
... there's a heads up for the packager that there could be a problem, because the time expressions don't
19:25:21 [nigel]
... necessarily use frames.
19:25:30 [nigel]
rrsagent, generate minutes
19:25:30 [RRSAgent]
I have made the request to generate nigel
19:29:55 [nigel]
nigel: I've created an issue for this.
19:29:57 [nigel]
19:29:57 [trackbot]
issue-381 -- Clarify timing concepts in relation to SMIL -- raised
19:29:57 [trackbot]
19:30:01 [nigel]
reopen issue-381
19:30:01 [trackbot]
Re-opened issue-381.
19:30:58 [nigel]
nigel: let's break for lunch.
19:31:01 [nigel]
rrsagent, generate minutes
19:31:01 [RRSAgent]
I have made the request to generate nigel
20:36:12 [tmichel]
tmichel has joined #tt
21:21:10 [glenn]
glenn has joined #tt
21:22:11 [dakim]
dakim has joined #tt
21:24:24 [nigel]
nigel: and we're back...
21:25:33 [courtney]
courtney has joined #tt
21:26:28 [nigel]
pal: I like the idea of defining root temporal extent in terms of resolved begin and end times
21:26:45 [nigel]
issue-381: Also define the root temporal extent in terms of resolved begin and end times
21:26:45 [trackbot]
Notes added to issue-381 Clarify timing concepts in relation to SMIL.
21:29:11 [nigel]
21:29:11 [trackbot]
issue-382 -- Require a computed non-indefinite begin time -- raised
21:29:11 [trackbot]
21:29:14 [nigel]
reopen issue-382
21:29:14 [trackbot]
Re-opened issue-382.
21:31:26 [nigel]
nigel: For reference, the issues regarding media offset and media begin are issue-361 and issue-270
21:32:09 [nigel]
nigel: There's one more point on timing I wanted to raise before we move off, which is the reference clock
21:32:23 [nigel]
... when timeBase="clock" and clockMode="local".
21:34:19 [nigel]
glenn: It's obvious what the intent was here - it's whatever clock is on the wall. It's the real time in the local time zone.
21:39:16 [nigel]
tai: So if someone sends you a document with local time then you don't know which local time they mean.
21:39:19 [nigel]
pal: What's the use case?
21:39:41 [nigel]
nigel: For example you have a reference clock source that's used to time media playback and you want to
21:40:06 [nigel]
... capture subtitles with times using the same clock source. Your definition of local time is independent,
21:40:38 [nigel]
... and you need some kind of identifier e.g. a PTP server, to be able to connect the recorded media with the
21:40:42 [nigel]
... TTML document.
21:40:57 [nigel]
glenn: That sounds application specific. Are you also saying you want to know the local time offset relative to UTC?
21:41:18 [nigel]
pal: If you know the UTC offset then why can't you just specify times in UTC?
21:42:42 [nigel]
glenn: So to be clear the intent is for playback only not recording time. So the idea is to say here's some timed
21:42:55 [nigel]
... text that doesn't have a related media object, or if it does then the synchronisation is out of scope.
21:43:23 [nigel]
nigel: But you can't detect that intention from any wording in the spec. It looks symmetrical regardless of
21:43:37 [nigel]
... whether times are captured times of recording or of intended times for presentation.
21:43:52 [nigel]
pal: So if something is synchronised locally with a local clock then it will work fine. The second you export the
21:44:09 [nigel]
... TTML document with a local timestamp I have no idea what that means - is it a local time against your watch,
21:44:22 [nigel]
... an atomic clock, or what. If you want to send it to me you need to convert the timestamps to UTC.
21:44:44 [nigel]
glenn: In SMIL the syntax for time expressions includes wallclock sync value. We modelled our local, utc and gps
21:45:00 [nigel]
... timebase on that wallclock value. Local in this case means the same as wallclock in SMIL. We extended it
21:45:31 [nigel]
... by adding UTC and GPS. If you change local to wallclock maybe that's clearer what it means.
21:45:38 [nigel]
nigel: That restates the ambiguity but doesn't resolve it.
21:47:39 [nigel]
glenn: It's easy enough for us to add something normatively about this, to say it's intended to mean the commonly understood wallclock value.
21:47:57 [nigel]
nigel: I don't want to do that though. Would you add a new clockMode e.g. "reference" and some metadata
21:48:03 [nigel]
... to identify the clock source?
21:48:05 [nigel]
glenn: We could do that.
21:48:42 [nigel]
nigel: I don't think we need that though. We could just add an interpretation of local that allows it to be
21:48:56 [nigel]
... parameterised with a reference clock source for example.
21:49:38 [nigel]
glenn: Since we were vague about it I don't see why we shouldn't constrain it to mean what we mean it to mean.
21:49:49 [nigel]
nigel: I'll add an issue to add this then.
21:52:14 [nigel]
tai: We (in EBU) have a need to define a local parameter localTimeOffset. There has been discussion and a use
21:52:29 [nigel]
... case identified for that. Another issue I could imagine is when you have two files relating to the same source
21:52:49 [nigel]
... media that's recorded and you put timeBase="clock" and clockMode="local" and then there's a summer time
21:53:05 [nigel]
... shift part way through the document, how can you translate to media time without knowing the timezone.
21:53:28 [nigel]
... For IRT we don't have that specific scenario but I think there are use cases from broadcasters in Europe that
21:53:44 [nigel]
... would need that extra information. We will define it in EBU, the question is if its useful in TTML more generally.
21:53:58 [nigel]
nigel: I would argue that it is, of course.
21:54:17 [nigel]
tai: We don't have an official request from EBU to add this, but we seem to be the main group member that
21:54:22 [nigel]
... thinks its useful.
21:56:04 [nigel]
pal: So you have two documents created by the same closed system one before a summer time shift the other after.
21:56:24 [nigel]
... When you export those, convert them to UTC! Don't send me a document with local times in.
21:56:46 [nigel]
... As a data point, in digital cinema local times have been a big source of confusion. My advice is just use UTC.
21:57:40 [nigel]
... The timezone adds nothing. It's just an offset relative to UTC, which changes locally in strange ways.
21:57:59 [nigel]
tai: You can still do that if you specify the offset correctly.
21:59:30 [nigel]
pal: My recommendation is just use UTC because then we definitely agree. Otherwise you have to keep track of DST.
21:59:48 [nigel]
nigel: But if you send qualified ISO 8601 times then the offset is clear regardless of DST.
22:00:00 [nigel]
pal: Yes, you can do that but my recommendation is don't even add offsets.
22:00:18 [nigel]
tai: I'm not sure if I agree because if for example you use the xs:date and xs:time schema formats in XML
22:00:34 [nigel]
... which define this kind of information that would be easy and does allow offsets to be included. It's easier
22:00:41 [nigel]
... not to make exceptions.
22:01:37 [nigel]
nigel: But we don't use XML date and time formats in the schema.
22:01:49 [nigel]
glenn: No we didn't define a schema with respect to date and time expressions.
22:02:50 [nigel]
tai: It's the same. If you put local and put this time zone then it would be the same as using UTC.
22:03:52 [nigel]
nigel: I've added issue-383 for this.
22:03:54 [nigel]
22:03:54 [trackbot]
issue-383 -- Clarify the application specific usages of clockMode="local" -- raised
22:03:54 [trackbot]
22:03:58 [nigel]
reopen issue-383
22:03:59 [trackbot]
Re-opened issue-383.
22:04:57 [nigel]
Topic: Spatial and Layout
22:05:14 [nigel]
nigel: We have ttp:pixelAspectRatio and ttp:storageAspectRatio as well as the new tts:position attribute.
22:05:54 [nigel]
pal: The reason I brought this up is that IMSC 1 has some language that we should make sure is consistent
22:06:23 [nigel]
... with TTML2, and also because there are lots of TBDs in TTML2. Maybe we're not ready for this yet?
22:06:42 [nigel]
... Last time I looked this wasn't well enough defined in the spec to come up with a conclusive interpretation.
22:06:50 [nigel]
glenn: [goes to the whiteboard]
22:07:55 [nigel]
glenn: In TTML1 we have tts:extent and tts:origin on regions. We have extent also on the root element tt:tt.
22:08:10 [nigel]
... We defined an implicit origin for the root element in the absence of external information. What this didn't
22:08:25 [nigel]
... do very well was to situate the extent of the document inside of a media element since it defaulted the
22:08:50 [nigel]
... root region to the top left without any considerations of aspect ratio or centering at all. In IMSC you define
22:09:11 [nigel]
... some default extent and origin sets to center the root and allow it to be contained within the related media
22:09:20 [nigel]
... object's extent while maintaining a certain aspect ratio.
22:09:39 [nigel]
pal: There's another mode, if you don't specify ittp:aspectRatio, which is to fill the entire region. If you do
22:09:51 [nigel]
... specify it then it fills the root container while preserving the aspect ratio.
22:11:02 [nigel]
pal: This is defined in IMSC 1 §6.7.1 (in the ED)
22:11:19 [nigel]
... It says preserve the aspect ratio and do it to make the width or height equal to that of the media object.
22:11:36 [nigel]
glenn: In this case the aspect ratio is effectively the display aspect ratio not the storage aspect ratio.
22:11:39 [nigel]
pal: I think that's right.
22:12:01 [nigel]
glenn: In TTML we have the pixel aspect ratio (PAR), and the display aspect ratio DAR is the PAR * SAR where
22:12:14 [nigel]
... the SAR is the storage aspect ratio. So in TTML2 I introduced a number of new features:
22:13:11 [nigel]
... Some extensions to the extent value which can now take "cover" and "contain" which relate to the tts:extent;
22:13:17 [nigel]
... The tts:position attribute;
22:13:27 [nigel]
... The ttp:storageAspectRatio parameter.
22:13:50 [nigel]
... The intention of "contain" is to allow the root container region to be computed so that the display aspect
22:14:14 [nigel]
... ratio is preserved without extending outside of the extent of the media object.
22:14:35 [nigel]
... "cover" also maintains the aspect ratio but does so without any margin, in other words it can compute the
22:15:08 [nigel]
... extent so that the root extent can extend beyond the media object, without necessarily centering. It also
22:15:14 [nigel]
... preserves the display aspect ratio.
22:16:28 [nigel]
... The extent has the same DAR as in the document root container region and completely covers the media object.
22:17:11 [nigel]
glenn: This isn't written in the spec yet - they're proposals from CSS. It may be that we don't need "cover". I
22:17:28 [nigel]
... included it for completeness. These are also useful for background image sizing.
22:17:46 [nigel]
... The second part of this is tts:position. I've defined that in TTML2 then if tts:position and tts:origin are present
22:18:10 [nigel]
... and a processor understands tts:position then tts:position takes precedence over tts:origin. The default
22:18:24 [nigel]
... for position is "center center".
22:18:29 [nigel]
pal: So position is an enumeration?
22:18:50 [nigel]
glenn: It is a complex expression that can have 1 to 4 terms two of which can be linked.
22:19:22 [nigel]
tai: Position relates to the root container region?
22:20:04 [nigel]
glenn: Look at the <position> definition. I defined it a bit more than CSS which is more prose-based.
22:20:28 [nigel]
pal: Can I check what the use cases are for this level of flexibility? Aside from preserving aspect ratio.
22:20:49 [nigel]
glenn: For example this simplifies the definition of regions. Let's say I want a 2 row region that is 1 row from
22:21:10 [nigel]
... the bottom of the screen regardless of the root container region, and I want it 80% of the width of the screen.
22:22:15 [nigel]
... What I can do is say tts:position="center bottom 10%" tts:extent="80% 20%" [draws picture]
22:22:40 [nigel]
pal: So we couldn't just do that with origin 70%?
22:23:41 [nigel]
glenn: It gets problematic when you want an offset but you're using extent="contains" for the root container region.
22:23:56 [nigel]
pal: So in IMSC you could specify origin 70% down and height 20%.
22:24:02 [nigel]
glenn: So that would yield the same percentage.
22:24:23 [nigel]
pal: So if you don't specify an aspect ratio it would still be true regardless of being square of cinemascope.
22:24:48 [nigel]
... Now if I specify an aspect ratio say 4:3 in a 4:3 container it would still work. If I specify 16:9 in a 4:3 container
22:25:19 [nigel]
... then it would end up 10% up still. So I think I can achieve the same already. I'm trying to see what we're
22:25:22 [nigel]
... missing in IMSC 1.
22:25:31 [nigel]
nigel: Can I throw in the definitions of vw and vh?
22:26:04 [nigel]
glenn: A better example would have been not using %age but position="center bottom 10vh" and extent="80vw 20vh"
22:27:19 [nigel]
... because I neglected that percentage is computed in an unusual way in the position construct. It would align
22:28:02 [nigel]
... the 70% point in the container with the 70% point in the box being contained. This makes center=50%.
22:29:07 [nigel]
nigel: There's now a picture of this in the section on tts:position.
22:30:14 [nigel]
glenn: You don't have to use the percentage system. You can use pixel or vh values, and they can be negative.
22:30:55 [nigel]
nigel: The percentages can be negative too?
22:31:15 [nigel]
glenn: Yes it looks that way. I just adopted this from CSS to support backgroundImage in the image element
22:31:35 [nigel]
... to have an adequate set of style properties and CSS has an image position property defined in these terms,
22:31:45 [nigel]
... which I thought we could reuse in this context.
22:32:36 [nigel]
nigel: I'm not sure but I think this might make TTML <--> WebVTT mapping easier because I have the
22:32:46 [nigel]
... impression that WebVTT uses the same mechanism. Can anyone confirm?
22:33:14 [nigel]
tai: I was thinking something similar, but it's a very different model from the current one, which may be a problem.
22:33:40 [nigel]
... From the usability perspective, the benefits of this are accompanied by additional complexity because it
22:33:48 [nigel]
... adds a new mechanism for something that is already present.
22:34:02 [nigel]
glenn: The extent and origin model in TTML was good when you knew fixed pixel values and were not
22:34:20 [nigel]
... concerned with maintaining fixed aspect ratios. It began to get difficult when we added auto extent computation
22:34:43 [nigel]
... and the need for positions like "center". So we already had a problem to specify the IMSC 1 behaviour as
22:35:16 [nigel]
... written. It's easy in this model - you just say tts:position="center".
22:35:49 [nigel]
... I've implemented this already and it wasn't complex.
22:36:11 [nigel]
... It was also more convenient authoring-wise rather than pre-computing values.
22:39:14 [nigel]
nigel: You raised the question of if "cover" is needed. I think it may be needed because for non-full screen
22:39:36 [nigel]
... video the user research I've seen suggests that placing the subtitles beneath the video is preferred.
22:39:51 [nigel]
pal: I think you need to make the distinction between the related media object and the viewport.
22:39:55 [nigel]
nigel: That's right.
22:40:29 [nigel]
glenn: I did mean to express whether the viewport is the related media object or the display. I think we need
22:40:35 [nigel]
... a way to define this.
22:41:11 [nigel]
glenn: ttp:storageAspectRatio is a natural follow-on from ttp:pixelAspectRatio.
22:41:31 [nigel]
pal: You have to define 2 out of the 3 to derive the third. I think defining DAR is better because it has more
22:41:51 [nigel]
... applicability and reduces the need for a calculation. This is supposed to be resolution independent.
22:42:19 [nigel]
pal: What about defining DAR and PAR but not SAR?
22:42:43 [nigel]
glenn: The thing is we defined extent on tt as basically the SAR. It has to be defined in logical pixels with the
22:42:51 [nigel]
... PAR pixel sizes.
22:43:14 [nigel]
nigel: So have we just defined SAR twice?
22:44:01 [nigel]
glenn: We didn't use those words specifically but the extent is the equivalent of the SAR.
22:44:59 [nigel]
... It's true that the goal is to maintain DAR, and I could have picked DAR or SAR.
22:45:48 [nigel]
glenn: We didn't mean SAR to be sample aspect ratio.
22:46:06 [nigel]
... In principle I don't see any reason off hand not to use DAR if that would be less confusing.
22:46:28 [nigel]
pal: My argument is that if we're trying to get to DAR we should just specify it. And also say you can calculate
22:46:44 [nigel]
... storage aspect ratio by dividing DAR by PAR.
22:47:48 [nigel]
glenn: The other thing I need to define for what a pixel means is the coordinate space. There are three that
22:47:52 [nigel]
... I've identified as relevant:
22:47:59 [nigel]
... 1. The document coordinate space;
22:48:08 [nigel]
... 2. The presentation context coordinate space;
22:48:27 [nigel]
... 3. The authoring context coordinate space (which may not be needed).
22:48:55 [nigel]
... From the perspective of presentation the first two are needed. The presentation context coordinate space
22:49:04 [nigel]
... may or may not be the display (glass) pixel coordinate space.
22:49:47 [nigel]
pal: So let's go to 'what is a pixel'. As soon as you define tts:extent in pixels then it's well defined. The
22:50:06 [nigel]
... definition of pixels is only an issue if you don't use tts:extent.
22:50:43 [nigel]
pal: If you define an extent in pixels e.g. 640x480, then whenever you use the measure pixels in the document
22:51:01 [nigel]
... you can always translate it to a percentage of the root container. We can always render it.
22:51:19 [nigel]
glenn: For TTML1 unfortunately we adopted the XSL definition of pixel, but I don't think anyone took any notice
22:51:35 [nigel]
... of it, and everyone just interpreted it as you said, as a logical definition.
22:51:56 [nigel]
pal: So I think we're trying to solve the case where there's a measure in pixels when tts:extent is not defined.
22:52:12 [nigel]
... I propose that we forbid the use of pixels when tts:extent is not defined.
22:52:29 [nigel]
... Or say if you do it then results are undefined.
22:53:22 [nigel]
glenn: That's one option. I'm not sure if I'm ready to accept it.
22:53:37 [nigel]
tai: I agree that it would be simpler to restrict something than to add something else. In the EBU group we
22:53:52 [nigel]
... spent 2-3 days discussing it and I'm not sure everyone had the same understanding at the end. We brought
22:54:04 [nigel]
... all these terms together.
22:54:25 [nigel]
glenn: Even if you use cover or contain and you have a viewport that you can resolve then eventually all the
22:54:42 [nigel]
... coordinates end up in some space in that viewport.
22:54:49 [nigel]
nigel: The question is do you need to?
22:55:03 [nigel]
pal: The world is heading towards resolution independence.
22:55:18 [nigel]
glenn: When I map TTML into SVG for example, SVG has a notion of a width and height on its root element and
22:55:32 [nigel]
... of its view box which defines a mapping between the extent of its coordinate space onto some other
22:55:56 [nigel]
... coordinate space. For example hxw = 100x100 and view box = 200x300 and it would multiply the coordinates
22:56:12 [nigel]
... by 2 and 3 to get to the same coordinate space. I think we can define something similar in this case so that
22:56:26 [nigel]
... there is a definition of a coordinate but the resolution of that coordinate may depend on some external
22:56:30 [nigel]
... context.
22:56:46 [nigel]
pal: I'm okay to allow it but have a weak definition and a hint or recommendation not to do it.
22:57:39 [nigel]
glenn: I've got a couple of these coordinate space terms.
22:58:13 [nigel]
... The document coordinate space is only really used in extent and position. I haven't folded it in anywhere else.
22:58:54 [nigel]
... There's an issue to define pixels in a concrete way.
23:00:44 [nigel]
nigel: As a devil's advocate straw man why do we not just say DAR is extent * pixelAspectRatio?
23:03:05 [nigel]
pal: So if you specify extent and pixelAspectRatio then you'd better make sure they multiply to DAR.
23:04:54 [nigel]
nigel: So we've created an over-constrained system by adding DAR.
23:05:53 [nigel]
pal: In IMSC 1 tts:extent is not used to compute DAR. It's only used to define what the px measure means.
23:07:17 [nigel]
nigel: We have a much bigger problem - tts:extent is defined in terms of <measure> which has been changed
23:07:35 [nigel]
... and can now have for example the value "available" - I don't know what that would mean here!
23:08:08 [nigel]
glenn: The changes to <measure> were in response to Sean's shrink fitting proposal.
23:08:37 [nigel]
... I pulled them in from CSS.
23:09:07 [nigel]
nigel: What does it mean if tts:extent uses those keywords in <measure> on the root element rather than
23:09:11 [nigel]
... scalar values?
23:09:57 [nigel]
glenn: I was also trying to satisfy the sizing of images.
23:11:18 [nigel]
nigel: It seems as though we need special care for the use of tts:extent on tt:tt, and many of the <measure>
23:11:25 [nigel]
... values don't have a clear meaning.
23:12:20 [nigel]
... Apologies I see that the wording "If tts:extent is specified on the tt element, then the width and height must be expressed in terms of two <length> specifications, and these specifications must be expressed as non-percentage, definite lengths using pixel units."
23:12:23 [nigel]
... is already present.
23:13:30 [nigel]
nigel: I'm struggling to see how we have not therefore already defined display aspect ratio.
23:15:13 [nigel]
glenn: That wording pasted above means that we can't specify "contain" and "cover".
23:15:36 [nigel]
nigel: It seems to me that "contain" and "cover" on tt:tt are orthogonal to the pixel extent.
23:15:38 [nigel]
glenn: They are.
23:17:01 [nigel]
nigel: But we don't have a way to specify both. Maybe the way out here is to allow DAR to be specified if
23:17:16 [nigel]
... extent on tt is "cover" or "contain" but not otherwise.
23:19:18 [nigel]
glenn and pal: discussion re the over-constraint of DAR, SAR and PAR if extent on root is in pixels and DAR is
23:19:21 [nigel]
... specified.
23:19:49 [nigel]
pal: I'd prefer to deprecate PAR and be done with it, but we could mandate the behaviour in the specific case
23:20:11 [nigel]
... where all three are specified and don't agree.
23:20:40 [nigel]
glenn: I'd rather put the wording in to define a single normative interpretation of the over-constrained but
23:20:55 [nigel]
... disagreeing scenario, so it's testable and consistent across implementations.
23:23:50 [nigel]
nigel: Do we have an issue for this?
23:24:16 [dakim]
dakim has joined #tt
23:24:27 [nigel]
glenn: The request is reasonable, to add DAR and remove SAR, but we don't have an issue for it.
23:24:36 [nigel]
nigel: Okay let's create an issue.
23:25:10 [nigel]
glenn: We already have issue-201
23:26:13 [nigel]
issue-201: [TTWG meeting 2015-04-09] Agreed to remove ttp:storageAspectRatio, add a display aspect ratio parameter and deal with overconstrained inconsistent extent in pixels on root, DAR and PAR.
23:26:13 [trackbot]
Notes added to issue-201 How to specify aspect ratio to understand positioning that may apply for display or video..
23:33:16 [nigel]
rrsagent, generate minutes
23:33:16 [RRSAgent]
I have made the request to generate nigel
23:34:41 [nigel]
Topic: ipd and bpd
23:35:42 [nigel]
glenn: This came about from my interpretation of the SMPTE Digital Cinema requirement for inline space.
23:36:01 [nigel]
pal: Yes, we wanted to be able to specify an inline space, positive or negative.
23:36:18 [nigel]
glenn: So there's already a width and a height property in CSS that are used for the same purpose, but the
23:36:31 [nigel]
... problem with those is their names. They're interpreted in a writing mode relative way, so for vertical
23:36:47 [nigel]
... writing modes width means height and height means width. I wanted to avoid that conundrum because we
23:37:04 [nigel]
... use them in their absolute meanings throughout the document. In XSL-FO there's already the concept of
23:37:37 [nigel]
... the inline progression dimension and the block progression dimension.
23:37:49 [nigel]
pal: So ipd allows a blank space to be defined in the inline direction?
23:38:31 [nigel]
glenn: No, it allows a size to be expressed, e.g. on a span, to define its size regardless of the content that it contains.
23:38:41 [nigel]
Courtney: What does this do if you have vertical text?
23:39:08 [nigel]
glenn: In vertical modes inline means vertical. bpd is the counterpart to that in the opposite axis, e.g. to allow
23:39:40 [nigel]
... a strut to be defined to separate lines by a specified amount.
23:40:31 [nigel]
pal: In TTML extent can only be applied to region...
23:40:54 [nigel]
glenn: Right, if you put extent on a div say then it is shorthand for an inline region.
23:41:04 [nigel]
pal: If you don't specify ipd on a div what's its computed value?
23:41:21 [nigel]
glenn: It's equal to its containing block's ipd minus border and padding if they apply.
23:41:52 [nigel]
pal: So it's a bit like padding for a content region by allowing them to be stretched until they reach that ipd?
23:45:29 [nigel]
glenn: [draws on whiteboard] showing how a div will use all of the width of its parent's content rectangle
23:45:39 [nigel]
... after taking into account the border and padding.
23:45:53 [nigel]
pal: That's all specified in CSS?
23:46:14 [nigel]
glenn: Right, except they use the terms width and height. The height of a div will be the minimum needed to
23:46:29 [nigel]
... hold its content. It will shrink in the block progression dimension to be the minimum needed to hold its
23:46:46 [nigel]
... children. If you specify ipd and bpd explicitly instead of allowing your layout engine to calculate it then
23:47:04 [nigel]
... things change. If for example you specify an ipd that's less than what would normally be present then it would
23:47:22 [nigel]
... be constrained to be narrower than it would normally be (horizontal writing mode). If you make it wider
23:48:26 [nigel]
... then you have an overflow condition - I need to check CSS as it may constrain the maximum allowed width.
23:49:47 [nigel]
... The original reason to have an ipd was to allow spacing to be created without using space characters
23:50:13 [nigel]
... for example by creating a <span tts:ipd="5em"/>.
23:50:34 [nigel]
tai: If you have a background color on all the spans the same...
23:51:24 [nigel]
glenn: then you'd have <span tts:backgroundColor="red">A<span tts:ipd="5em"/>bad<span tts:ipd="5em"/>boy</span>
23:51:41 [nigel]
... for example. The background colour is drawn behind the extent even if it doesn't have any content in it.
23:51:58 [nigel]
... You could have <span tts:ipd="5em" tts:backgroundColor="blue"/>
23:52:21 [nigel]
... That's how they came about. The request was just for ipd but I added bpd for symmetry.
23:52:34 [nigel]
nigel: And last time we discussed this some folk were unhappy with the attribute names.
23:55:17 [nigel]
nigel: I'm not sure if that's still true. How about an alternative like "inlineSize" and "blockSize"?
23:56:55 [nigel]
... The issue with the term 'dimension' is that it's used as a direction in some places in TTML.
23:57:12 [nigel]
glenn: In XSL it's used as a size as distinct from inline progression direction.
23:57:37 [glenn]
ACTION: glenn to ensure consistency in TTML2 w.r.t. inline progression dimension vs direction
23:57:37 [trackbot]
Created ACTION-384 - Ensure consistency in ttml2 w.r.t. inline progression dimension vs direction [on Glenn Adams - due 2015-04-16].
23:58:17 [nigel]
nigel: Will that resolve it for everyone?
23:58:30 [nigel]
group: no objections to this approach, and keeping the names ipd and bpd.
23:59:20 [nigel]
Topic: Condition structure