Re: {minutes} TTWG Meeting 2014-12-04

a couple of corrections/clarifications

On Thu, Dec 4, 2014 at 9:11 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

>  Thanks all for attending today's meeting. Minutes in HTML format can be
> found at: http://www.w3.org/2014/12/04-tt-minutes.html
>
>  *TTML2 issues closure*:
>
>  If there are no unresolved comments remaining we will close the
> following Pending Review Issues:
>
>  Thu 11th December TTWG meeting: issues numbered: 10, 230, 238, 239, 240,
> 241, 242, 244, 245, 246, 247, 248, 249, 250, 273, 287, 289, 290, 291 and
> 292.
>
>  Thu 18th December TTWG meeting: issues numbered: 21, 213, 236, 237, 285,
> 286 and 294.
>
>  Please review the solutions in the current editor's draft [TTML2ED] and
> raise any concerns offline prior to the meeting as far as possible, so that
> we can get through these in the time available.
>
>  Note that closure now will not prevent issues from being reopened or new
> related issues from being opened later for any reason, but allows us to
> verify that some apparently suitable solution has been implemented.
>
>  [PRI] https://www.w3.org/AudioVideo/TT/tracker/issues/pendingreview
> [TTML2ED]
> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html
>
>
>  *Minutes in text format:*
>
>     [1]W3C
>
>       [1] http://www.w3.org/
>
>                 Timed Text Working Group Teleconference
>
> 04 Dec 2014
>
>    See also: [2]IRC log
>
>       [2] http://www.w3.org/2014/12/04-tt-irc
>
> Attendees
>
>    Present
>           glenn, pal, Thierry, Andreas, nigel, jdsmith, mike,
>           courtney
>
>    Regrets
>           Frans
>
>    Chair
>           nigel
>
>    Scribe
>           nigel
>
> Contents
>
>      * [3]Topics
>          1. [4]This meeting
>          2. [5]IMSC 1 transition to CR
>          3. [6]Action Items
>          4. [7]Issues
>          5. [8]AOB
>      * [9]Summary of Action Items
>      __________________________________________________________
>
>    <trackbot> Date: 04 December 2014
>
>    <scribe> scribeNick: nigel
>
> This meeting
>
>    nigel: is there AOB?
>    ... We should mention the ITU-R WP6B liaison
>
> IMSC 1 transition to CR
>
>    nigel: Pierre and I met the Director and plh and Thierry
>    yesterday to discuss transition of IMSC 1 to CR.
>    ... [result not minuted]
>
>    action-333?
>
>    <trackbot> action-333 -- Pierre-Anthony Lemieux to Create a one
>    pager to cover the plan for the director's meeting for taking
>    imsc1 to cr. -- due 2014-11-27 -- PENDINGREVIEW
>
>    <trackbot>
>    [10]http://www.w3.org/AudioVideo/TT/tracker/actions/333
>
>      [10] http://www.w3.org/AudioVideo/TT/tracker/actions/333
>
>    close action-333
>
>    <trackbot> Closed action-333.
>
>    tmichel: The document will be published on Dec 9 and then I'll
>    send the call for implementation announcement
>    ... on the same day. It will also be advertised on the W3C
>    homepage.
>    ... The webmaster has approved the document today.
>    ... (so it is now frozen)
>
>    nigel and pal: Thanks everyone for the work put into this
>    document.
>
>    glenn: Congratulations.
>
>    pal: The next step is to start compiling our test suite and
>    test material. I plan to translate the DECE
>    ... submission into what I think is valid IMSC 1 documents -
>    primarily a change to namespace.
>    ... Also I'm going to reach out to implementors. Would the
>    group also be interested in a more formal
>    ... message or template message to send to those who are
>    interested. How do we proceed?
>
>    tmichel: The Call for Implementations is sent out to the chairs
>    and ac-forum and will be published on the W3C homepage.
>    ... That will be done on the day of publication. We can take
>    that message and send it to whomever we want.
>    ... We need to wait until publication.
>
>    pal: Does that make it easy for people who want to contribute
>    to know who to contact?
>
>    tmichel: I'll send a link. Basically it says the spec is now in
>    CR and invites participation for implementation.
>    ... It also says how to feedback to the public mailing list.
>
>    pal: Thank you. Also there are Simon's outstanding comments
>    that have been deferred. Can we discuss that
>    ... next week?
>
>    nigel: Okay.
>
> Action Items
>
>    action-356?
>
>    <trackbot> action-356 -- Nigel Megitt to Request review of
>    ttml2 pending review issues from group -- due 2014-12-04 --
>    PENDINGREVIEW
>
>    <trackbot>
>    [11]http://www.w3.org/AudioVideo/TT/tracker/actions/356
>
>      [11] http://www.w3.org/AudioVideo/TT/tracker/actions/356
>
>    close action-356
>
>    <trackbot> Closed action-356.
>
>    nigel: I should list the issues that have been implemented
>    since last week, for review on 18th December,
>    ... a similar timescale.
>
>    glenn: The list is: 21, 213, 236, 237, 285, 286, 294. Those are
>    all the new ones since last week.
>
>    action-355?
>
>    <trackbot> action-355 -- Glenn Adams to Resolve duplication
>    between issue-357 and issue-229 -- due 2014-12-04 -- OPEN
>
>    <trackbot>
>    [12]http://www.w3.org/AudioVideo/TT/tracker/actions/355
>
>      [12] http://www.w3.org/AudioVideo/TT/tracker/actions/355
>
>    glenn: I've been focusing on the issues so I've not done work
>    on this AI or any of the others.
>
>    action-354?
>
>    <trackbot> action-354 -- Mike Dolan to Investigate formal
>    contact at arib -- due 2014-11-27 -- OPEN
>
>    <trackbot>
>    [13]http://www.w3.org/AudioVideo/TT/tracker/actions/354
>
>      [13] http://www.w3.org/AudioVideo/TT/tracker/actions/354
>
>    mike: Status is: I reached out to the executive director of
>    ARIB and he's going to get back to me.
>    ... Somewhat unrelated, a colleague from Toshiba indicated some
>    other practical aspects of the ARIB work
>    ... so that's interesting too. It looks like another 6 months
>    to a year before it's out for basic UHDTV.
>    ... Hopefully before the holidays we'll have specific logistics
>    for how to work with them to add
>    ... the extensions to TTML2.
>
> Issues
>
>    issue-21?
>
>    <trackbot> issue-21 -- window anchor points not supported? --
>    pending review
>
>    <trackbot>
>    [14]http://www.w3.org/AudioVideo/TT/tracker/issues/21
>
>      [14] http://www.w3.org/AudioVideo/TT/tracker/issues/21
>
>    glenn: This is about positioning the root container region more
>    flexibly, or other regions relative to it.
>    ... I'm proposing a new tts:position style attribute fairly
>    closely related to the backgroundPosition property
>    ... in CSS 3 image backgrounds and borders. For example you
>    could say "position the bottom edge of the
>    ... region 20% above the bottom edge of the container region".
>    ... So you could say 10% bottom, or center, which would center
>    the region in its container region.
>    ... Take a look at that - I think it will be interesting. I've
>    defined it so that if you have both tts:origin and
>    ... tts:position then in a TTML2 context you'd ignore
>    tts:origin and use tts:position, otherwise you can
>    ... still use tts:origin as a fallback. The presentation in
>    that case may end up different of course.
>
>    pal: Do we really need this feature? Positioning has been
>    problematic for a number of implementors in
>    ... the past so I'm concerned about the complexity. What is the
>    use case?
>
>    glenn: I'm responding to the issue - someone requested anchor
>    points so I've provided a solution.
>
>    pal: This issue was opened in 2008.
>
>    glenn: We should bear in mind that there are general uses for
>    TTML2 not just captioning and subtitling.
>    ... There are features that need similar features. We shouldn't
>    confuse implementation complexity with
>    ... syntax complexity. Many browsers implement the CSS feature
>    too, so there are implementations.
>
>    mike: How would this work? If you have overflow, extent etc
>    what would happen? Would the anchor remain
>    ... where it was set. That needs to be addressed.
>
>    glenn: This only addresses position of the region, not extent
>    or overflow, which are separate.
>    ... In order to compute the position you have to have resolved
>    the extent already. The overflow issue
>    ... is independent of positioning and sizing. So this is only
>    related to position.
>
>    mike: I think the combination of the two could result in some
>    interesting effects depending on how it is
>    ... defined.
>
>    glenn: There are some extensions coming to the extent
>    attribute, including the ability to say it should be
>    ... computed so that the result is contained in the outer
>    containing block, for example if you're sizing the
>    ... root container region to ensure it fits in the available
>    area of the related media object, and needs to be
>    ... in the center, you'd specify extent="contain" and
>    position="center" and the semantics would work
>    ... alongside another new parameter storageAspectRatio which
>    constrains the related media object's
>    ... shape. Then the root container region is positioned
>    correctly.
>
>    mike: I think the original issue (could have been me, I'm not
>    sure!) needs to be mapped from 708 semantics
>    ... into this, whatever we end up doing. I share some of pal's
>    concerns re complexity.
>
>    glenn: I agree, and would point out that it's bad design in my
>    opinion to throw out possible features early
>    ... in the process. It's better to propose solutions that can
>    be considered. As the process moves forward
>    ... we can see if they will be implemented and do what is
>    needed, rather than cutting them out too soon.
>    ... This also establishes IPR precedent and commitment by
>    putting them into the FPWD even if they don't
>    ... end up in the final version. This is the wrong time to
>    discuss complexity.
>
>    atai: We discussed anchor points in the EBU group some years
>    ago with Sean Hayes. We mostly discussed
>    ... positioning of the region within the root container. We
>    didn't talk about positioning the root container
>    ... in relation to the media object. Just a note. I'm not sure
>    if we have an option for simplification there.
>
>    glenn: THere are three applications: 1) positioning the root
>    container region wrt the display or the media object.
>    ... For example a 16:9 display showing a 2:1 media - you may
>
> s/2:1/2.21:1/

>    want to position the subtitles in the black
>    ... bar beneath the video.
>    ... 2) Positioning the region within the root container region.
>    ... 3) Positioning background images relative to content or a
>    region. The border rectangle, padding
>    ... rectangle and content rectangle need to be considered.
>
>    issue-213?
>
>    <trackbot> issue-213 -- Advance notice of deprecation for
>    textOutline -- pending review
>
>    <trackbot>
>    [15]http://www.w3.org/AudioVideo/TT/tracker/issues/213
>
>      [15] http://www.w3.org/AudioVideo/TT/tracker/issues/213
>
>    glenn: There's no action - I don't propose that we don't
>    deprecate textOutline.
>
> I may have said this poorly, but I am proposing we DO NOT DEPRECATE
tts:textOutline. In other words, I am proposing the NO ACTION option.

>  I'll be drafting the
>    ... orthogonal text shadow feature, but they're independent of
>    each other.
>    ... It's already in TTML1 so I propose to keep it.
>
> "It's" = "tts:ttextOutline is"

>
>    mike: As long as we end up having the 708 features that can't
>    be emulated with textOutline (drop shadow support).
>
>    glenn: The way we defined textOutline is that it extends
>    perpendicular to the tangent of the outline of the
>    ... glyph at any given point, inner or outer. textShadow is an
>    x-y offset vector that translates the outline
>    ... without changing its size.
>
>    mike: My concern isn't textOutline but making sure we have text
>    shadow.
>
>    courtney: I think that means you won't be able to support all
>    the FCC regulations in TTML.
>
>    glenn: I'm proposing not deprecating, so both are available,
>    and I believe it will support all of the options.
>    ... We will need to go through all of the 708 edge styles and
>    verify that they can be achieved.
>
>    PROPOSAL: Close this issue.
>
>    close issue-213
>
>    <trackbot> Closed issue-213.
>
>    issue-236?
>
>    <trackbot> issue-236 -- Character spacing, i.e. letter-spacing
>    -- pending review
>
>    <trackbot>
>    [16]http://www.w3.org/AudioVideo/TT/tracker/issues/236
>
>      [16] http://www.w3.org/AudioVideo/TT/tracker/issues/236
>
>    glenn: this allows introducing tracking in the same way as CSS
>    letter spacing. I've introduced it.
>
>    issue-237?
>
>    <trackbot> issue-237 -- Inline space -- pending review
>
>    <trackbot>
>    [17]http://www.w3.org/AudioVideo/TT/tracker/issues/237
>
>      [17] http://www.w3.org/AudioVideo/TT/tracker/issues/237
>
>    glenn: This is similar - inline space allows the width of an
>    inline box that contains some glyphs,
>    ... for example a span with some content in it within a
>    paragraph. I might want to say 14% of the region
>    ... width, etc. It turns out that in CSS and XSL-FO there are
>    both width and height properties that apply
>    ... to content elements however the semantics are such that for
>    inline non-replaced elements like span,
>    ... width and height are ignored! So, what to do? It turns out
>    there's a nice mechanism in CSS which I'd
>    ... overlooked for a while, called display:inline-block. While
>    you can't say that an inline block is a
>
> s/inline block/inline area/

>    ... particular width you can say that a block in an inline
>    context is a particular width and height. So I
>    ... introduced those concepts, and said that they magically
>    turn spans into inline blocks to which width
>    ... and height can apply. I've tested it in various browsers
>    and it does exactly what you'd think it does.
>
>    issue-285?
>
>    <trackbot> issue-285 -- Align rendered rows within a region to
>    each other, and the set to the region -- pending review
>
>    <trackbot>
>    [18]http://www.w3.org/AudioVideo/TT/tracker/issues/285
>
>      [18] http://www.w3.org/AudioVideo/TT/tracker/issues/285
>
>    glenn: This is the long standing EBU request for multiRowAlign.
>    We've played around with some options.
>    ... We looked at flexbox, but I recently realised that the
>    inline block mechanism I just described can
>    ... satisfy the same requirement. E.g. A paragraph with a
>    single span in it, the p being the whole width of
>    ... the root container region, and you want to centre the text,
>    but align any broken lines left or right to
>    ... each other within that centre-aligned paragraph. The inline
>    block mechanism allows that too.
>    ... You can specify a separate alignment on the content of the
>    span and that will allow two alignments,
>    ... one to the content of the paragraph and the other to the
>    span. My experiments on browsers show
>    ... this works as desired. If you specify a textAlign on span,
>    which is new, then it results in the promotion of
>    ... the span to an inline block for display purposes. That
>    would allow for example left justified lines in a
>    ... center aligned paragraph.
>    ... This separates out the concepts so the existing semantics
>    don't have to change.
>
>    atai: This is an interesting approach that the EBU group should
>    review. I'm not sure it matches the intended
>    ... presentation - does it align multiple lines of text with
>    the longest line in the group? For example
>    ... a centred first (and longest) line, with the second line
>    right aligned to it? Would this work?
>
>    glenn: I'm not sure. I need a written down sample or example to
>    check. My proposal does work when
>    ... the line breaks are defined with br elements. If two lines
>    are wrapped in a span with textAlign="right"
>    ... and contained in a paragraph with textAlign="center" then
>    it would first layout the block right aligned
>    ... and then centre the whole block as the paragraph. So this
>    would have the result you want.
>
>    atai: ok
>
>    glenn: I'd be interested in scenarios where this might not
>    work, according to my reading of the EBU spec.
>
>    issue-286?
>
>    <trackbot> issue-286 -- Extend the background area behind
>    rendered text to improve readability -- pending review
>
>    <trackbot>
>    [19]http://www.w3.org/AudioVideo/TT/tracker/issues/286
>
>      [19] http://www.w3.org/AudioVideo/TT/tracker/issues/286
>
>    glenn: I fixed that by allowing padding to be assigned to a
>    span, and saying if done, it must use
>    ... box-decoration-break:clone semantics.
>
>    issue-294?
>
>    <trackbot> issue-294 -- Style attribute to prevent overflow by
>    shrinking text to fit on a line -- pending review
>
>    <trackbot>
>    [20]http://www.w3.org/AudioVideo/TT/tracker/issues/294
>
>      [20] http://www.w3.org/AudioVideo/TT/tracker/issues/294
>
>    glenn: This is one that I believe John Birch specified and I
>    said that the proposal was about content
>    ... fitting, e.g. automatically reducing the font size to fit
>    the content. Nobody in CSS land or elsewhere
>    ... is doing that, so it would be highly complex to implement.
>    However the region can now be shrink-fit
>    ... to the content. I've proposed a new value for tts:extent:
>    "fit-content" that comes out of a CSS3 spec.
>
>    issue-307?
>
>    <trackbot> issue-307 -- Conformance language and processor
>    profile rather than content profile. -- pending review
>
>    <trackbot>
>    [21]http://www.w3.org/AudioVideo/TT/tracker/issues/307
>
>      [21] http://www.w3.org/AudioVideo/TT/tracker/issues/307
>
>    nigel: Since relevant changes have been made I propose to close
>    this with no further action.
>
>    close issue-307
>
>    <trackbot> Closed issue-307.
>
> AOB
>
>    nigel: Please note the liaison from ITU-R WP 6B which came in
>    earlier today and went to member-tt.
>    ... They would like a liaison I think, want to know about our
>    work on WebVTT and IMSC 1 and how
>    ... they relate to each other. They also have some detail
>    questions on IMSC 1.
>
>    pal: I'm happy to draft a first response on those IMSC 1
>    questions.
>
>    <scribe> ACTION: pal Draft response to ITU-R liaison re IMSC 1
>    questions. [recorded in
>    [22]http://www.w3.org/2014/12/04-tt-minutes.html#action01]
>
>    <trackbot> Created ACTION-358 - Draft response to itu-r liaison
>    re imsc 1 questions. [on Pierre-Anthony Lemieux - due
>    2014-12-11].
>
>    glenn: I notice the liaison also mentions the ARIB-TT
>    development.
>
>    nigel: Yes, I encourage everyone to have a look at the liaison
>    document.
>    ... For next week we have 1 hour set aside and a lot of issues
>    to close on TTML2, hopefully, so in the
>    ... interests of time please could everyone discuss them
>    offline on the reflector as much as possible, so
>    ... we only have to discuss the minimum number of questions?
>
>    [adjourns meeting]
>
> Summary of Action Items
>
>    [NEW] ACTION: pal Draft response to ITU-R liaison re IMSC 1
>    questions. [recorded in
>    [23]http://www.w3.org/2014/12/04-tt-minutes.html#action01]
>
>    [End of minutes]
>      __________________________________________________________
>
>
>     Minutes formatted by David Booth's [24]scribe.perl version
>     1.140 ([25]CVS log)
>     $Date: 2014-12-04 16:06:51 $
>
>      [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
>      [25] http://dev.w3.org/cvsweb/2002/scribe/
>
>
>