{minutes} TTWG Meeting 2017-06-01

Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/06/01-tt-minutes.html


We need to close off work on the TTML2 WR in the next 2 weeks so that we can verify that we have consensus to publish, so please review as soon as possible and try to track the edits merged in the repo so that we can try to avoid any late slew of new issues.


In text format:


   [1]W3C

      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

01 Jun 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/06/01-tt-irc

Attendees

   Present
          Glenn, Andreas, Mike, Thierry

   Regrets
          Dae, Pierre

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This Meeting
         2. [5]TTML issue assignment and progress tracking
         3. [6]TTML1 & TTML2 issues, actions, PRs, editorial
            actions etc
         4. [7]Line Gap
         5. [8]#200 Two value percentage font sizes
         6. [9]Meeting close
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This Meeting

   Nigel: For today, we have TTML stuff - issues, progress, TTML1
   vs 2 compatibility, a little
   ... on IMSC that's in the agenda (even in Pierre's absence).
   Any thing specific to raise or AOB?

   group: [silence]

   Nigel: Okay then let's do it!

TTML issue assignment and progress tracking

   Nigel: I just want to recognise the huge amount of work that
   Glenn has done on TTML2
   ... over the last month.

   Glenn: I won't be able to make the telcos in June but will be
   able to work offline by
   ... email.

   Nigel: So there's no point in proposing to move the meetings?

   Glenn: No, I still wouldn't be able to attend.
   ... In terms of progress I have only 1 issue remaining for
   which there is no PR.
   ... The priority will be to wrap up the PRs and get to a
   version for WR. There may be
   ... some other issues that I will address too, some of them
   recent, like not deprecating
   ... ttp:profile. I don't know if I will be able to address the
   24 or so issues raised by
   ... Richard Ishida, but if there are simple ones I will try to
   do that.
   ... For #195 on audio description I posted a preliminary PR
   which is not complete.
   ... I see there are comments on that from you Nigel which I
   will look at, so that's also
   ... on my list for June. I want to get all that work done by
   23rd June which will give a
   ... week to prepare a final version of the WR and deal with any
   publishing issues.

   Nigel: Our goal is to publish WR by end of June. Can we have a
   completed draft by
   ... 15th June to give 2 weeks review to verify that we have
   consensus?
   ... Any commits after then, unless they are addressing review
   comments, might not make it in.

   Glenn: Ok I'll see how far I can get by the 15th.
   ... I'd like to talk today about the proposal for dealing with
   line gap, and the other
   ... is the lingering issues about em square and font size
   semantics.

   Nigel: Ok, what about mediaOffset?

   Glenn: The last issue I have, #96 on root temporal extent,
   encompasses that so I'm
   ... not yet ready to review that today - I'm still working on
   it.

   Nigel: Ok

   Glenn: That's a case where maybe we need a special call with
   interested parties to
   ... drill down into the details of that one.

   Nigel: Sounds like a good idea.
   ... Status right now on TTML2:
   ... 44 open issues.
   ... 7 issues for group review or awaiting HR comment on
   disposition
   ... 28 open issues with no milestone
   ... (19 are horizontal review comments)
   ... 9 open on the Editor's WR work list.
   ... Glenn is there anything specific where it would be useful
   for input from others, e.g.
   ... editorial notes, examples?

   Glenn: Not right now, #150 is the only one on here.
   ... I'd like to talk about today.

   Nigel: Before we dive into the issues, are there any other
   changes anyone has begun
   ... to work on?

   group: [silence]

TTML1 & TTML2 issues, actions, PRs, editorial actions etc

   [12]Revert deprecation of ttp:profile on root element. #331

     [12] https://github.com/w3c/ttml2/issues/331

   Glenn: I posted a pull request on this last night that reverts
   the deprecation.

   Nigel: There are two things to discuss here - the TTML1 vs
   TTML2 goal and the
   ... behaviour for ttp:profile if ttp:processorProfiles is also
   present.

   Mike: I want a statement at the beginning of the document that
   states that all TTML1
   ... document instances shall be valid TTML2 documents. The
   handling of deprecations
   ... is delegated to the places where those deprecations are
   defined.

   Glenn: I don't see a problem with stating that as an
   informative note.

   Mike: That's what I have in mind.

   Glenn: If you say "should validate" that's complex, maybe
   "should remain conformant"
   ... would be better. Validation may create warnings as well as
   errors. So a TTML2 based
   ... validation processor may emit warnings when processing a
   TTML1 document that
   ... uses something that's deprecated.

   Mike: I had it right on the email - the important thing is to
   state informatively this
   ... goal at the beginning of the document, which should guide
   us on not obsoleting
   ... anything. I was concerned until I checked the meaning of
   "deprecate".
   ... I think we should use "conformant" language rather than
   "deprecate".

   Glenn: Another interesting thing is the scenario of processing
   a TTML1 document
   ... under TTML2 rules rather than TTML1 rules. This could be
   done by a configuration
   ... parameter.

   Mike: That would be good to mention - we're not changing the
   namespace are we?

   Glenn: No we're not changing that.

   Mike: It would be helpful to discriminate old from new
   documents.

   Glenn: For example I could take a TTML1 document and add a v2
   attribute to it. It is
   ... no longer strictly a TTML1 document because it has a
   version attribute. Now I feed
   ... that to a TTML2 processor

   Nigel: So your point is that the processing of a TTML1 document
   under TTML2
   ... rules might generate different output from the same
   document processed under
   ... TTML1 rules?

   Glenn: I just wanted to point out there are subtleties.

   Andreas: I have a question about handling of TTML1 documents by
   a presentation
   ... processor. Is the presented result identical from a TTML2
   processor as from a TTML1
   ... processor? Is that also guaranteed?

   Glenn: I doubt if you get that with TTML1 processors.

   Andreas: But I mean the intent.

   Glenn: It's not true in general because you cannot guarantee
   what fonts are used, and
   ... the line breaking algorithm is not specified.

   Andreas: My question is: is there any difference in TTML2 that
   would result in a
   ... different rendering from a TTML 1 processor, having taken
   out the non-deterministic parts?

   Glenn: If the implementations have the same fonts, the same
   rasterisation processing
   ... and font implementation, and we assume that we are not
   considering implementatoin
   ... dependent differences. If you throw out all those variables
   then it probably should
   ... be close but I don't know if it would be exact even in
   theory. I don't think anything
   ... in TTML1 right now says the output of a presentation engine
   has to be identical.
   ... We don't have a testing regime to verify that.

   Nigel: I'd flip this round and look for counter-examples. One
   of those is the handling
   ... of tts:origin and tts:extent on div and p elements.
   Presentation behaviour is not
   ... defined in TTML1 for that but it is in TTML2 so the two
   processing engines should
   ... generate different output given a document that uses that
   syntax.

   Andreas: I think that example is interesting. I think if we add
   such a statement, we
   ... should add that all TTML1 documents should be processed
   okay by a TTML2
   ... processor, and that changes in TTML2 do not lead to
   different results than a TTML1
   ... processor. That is if we can be sure. Otherwise we should
   just state that document
   ... conformance is given for TTML1 documents as being valid
   TTML2 documents.

   Glenn: In TTML1 we define 3 standard profiles - full,
   presentation and transformation.
   ... We tied those to v1 and in v2 that we are defining now we
   have created new
   ... profiles with the same names but slightly altered. Now
   instead of dfxp-full etc we
   ... have ttml2-full, ttml2-presentation and
   ttml2-transformation, so we have two sets
   ... of built-in profiles, one that applies to TTML1 and the
   other to TTML2. We are also
   ... extending the set of feature designators in TTML2. So a
   TTML2 processor can
   ... choose only to treat documents as TTML2 or to process TTML1
   documents as
   ... faithfully to TTML1 as it can, except if ttp:version="2"
   which may lead to slightly
   ... different presentation potentially.

   Nigel: In summary, we should not state that a TTML2 processor
   will generate the same
   ... output as a TTML1 processor for the same conformant TTML1
   document, since we
   ... do not know in general that it is the case.

   Glenn: I think we should put this note in the Conformance
   section.

   Mike: Shall I file an issue?

   Nigel: Yes please do it so we can track it.

   Mike: On this issue, can I refer to it?

   Glenn: We need to make sure that we deal with the "used value"
   of ttp:version.

   Nigel: Are you happy for #331 to bring back the wording about
   precedence in case
   ... ttp:profile and ttp:processorProfiles are present?

   Glenn: I thought there was some procedural wording there, I'll
   verify and if not then
   ... yes I'll put that wording back.

   Mike: I think we should not permit both to be present in the
   same document instance.

   Glenn: We do not prohibit content inside the TTML document.
   ... You may do that in a profile.

   Mike: Why allow both in the same document?

   Glenn: You should not but we cannot enforce author behaviour so
   we define what
   ... the processor does. It is clearly not violating a syntactic
   rule and we do not want to
   ... insist on a schema based rule to enforce it so we have
   semantic language that says
   ... you should not do both.

   Mike: I think that's weird but I understand that's the common
   practice so I'll back off.

   Glenn: This is the case for origin and position too, for
   example.

   Nigel: I agree even if the authoring practice is not good we
   should have a defined
   ... behaviour rather than an undefined one.

   Mike: Ok!

   Glenn: I agree we need language to say you shouldn't do both
   and what to do if they
   ... are both present so I'll make sure that's there.

   Mike: Thank you.

   Glenn: I can handle the addition of a conformance note to #331.

   Mike: I'll raise an issue about the obsoleted feature.

Line Gap

   [13]Ways to make span background height be lineHeight #150

     [13] https://github.com/w3c/ttml2/issues/150

   Nigel: Glenn you requested here and on IMSC to make this a
   parameter attribute
   ... rather than a style attribute.
   ... We did discuss this for IMSC and concluded that it should
   be a style attribute.

   Andreas: I tried to find this in the minutes from the London
   minutes, but as far as I
   ... recall we had this discussion and even then Glenn wanted
   just one attribute for the
   ... whole document; others had the strong view that it should
   be a style attribute.
   ... I cannot remember exactly the use case. I think we
   definitely discussed the solution
   ... and agreed to have it as a style attribute.

   Nigel: +1

   Glenn: I agree that's what we discussed.
   ... I'm not convinced at all that a single document instance
   would use more than one
   ... value at any point. I expect that documents would declare a
   style attribute as a top
   ... level inherited value or an initial value so they will have
   the same value everywhere.
   ... If we started out with a profile version we could add a
   style version later for
   ... more refinement.
   ... I think we don't have a requirement for it and it makes
   implementations and testing
   ... more complicated.

   Nigel: Glenn you asked me for an example - I added one to the
   pull request

   [14]Issue 0150 inline background height #346

     [14] https://github.com/w3c/ttml2/pull/346

   Nigel: This is based on the HbbTV 2.0.1 heuristic that does
   allow for documents to
   ... vary the line gap filling behaviour, so a single ttp:
   namespace attribute would not
   ... allow this example to work.

   Andreas: We discussed this and decided the other way around. I
   think we should take
   ... it for granted that there is a requirement to apply it as a
   style to a paragraph, so it
   ... is not sufficient to have a document wide setting.

   Nigel: +1

   [15]Change itts:fillLineGap to ittp:fillLineGap. #238

     [15] https://github.com/w3c/imsc/issues/238

   Glenn: Since it is a style attribute in IMSC 1.0.1 I will close
   the issue and go back to
   ... a style attribute - I don't particularly like it!
   ... Are you happy if I make the change to #346 that I can merge
   it.

   Nigel: Please could you make the change and then allow us time
   to double check it?

   Glenn: Ok. By the way the reason I ended up going this way is
   because earlier on I had
   ... proposed special values in bpd, but the more I tried that
   the more conflicts I uncovered
   ... so doing something special is warranted. bpd and ipd do not
   apply to inline areas
   ... that are not inline blocks so coming up with special
   language was too strange and
   ... complicated to manage.

#200 Two value percentage font sizes

   [16]Two value percentage fontSize not fully defined #200

     [16] https://github.com/w3c/ttml2/issues/200

   Nigel: I'm concerned that we are removing the semantic that
   allows the author to
   ... define only the font height and have the processor present
   the glyphs without
   ... any anamorphic scaling, possibly with knowledge of the
   display aspect ratio.

   Glenn: It is already the case that font size has a defined
   width and height for the em
   ... square. Logical pixels do not have any aspect ratio and we
   are talking about logical
   ... pixel space here. When we scale the em square to a logical
   width and height...

   [discussion of issue - scribe thinking not typing!]

   Nigel: [Presents starting condition of no tts:extent on root,
   use of %age dimensions,
   ... implementation chooses what SAR, DAR etc to calculate.]

   Glenn: [walks through this]
   ... e.g. for a 4:3 display the implementation would choose a
   SAR of e.g. 640x480.
   ... That's up to the implementation to decide. Now we have
   SAR=DAR and PAR=1.
   ... In this case all logical pixels map to square display
   pixels so if you specify a fontSize
   ... of say "10%" on the region then you get logical pixels 64
   high and 64 wide. Since
   ... here we are mapping those to square display pixels you end
   up with a square em
   ... square.

   Nigel: Okay I think you might have persuaded me - if you
   switched to a 16:9 display
   ... you would get more horizontal pixels and they would still
   be square.
   ... By the way the issue originally arose because, although in
   the case we just went
   ... through, the SAR is known, in a transformation processor it
   can not always be
   ... known. There is one trick we could play which is to
   consider the horizontal width
   ... as an equivalent rh value (i.e. width is a proportion of
   the height).

   Glenn: That's in the PR.

   Nigel: That's PR #336, which is merged.

   Glenn: There's a note example under fontSize.

   Nigel: Is it clear which pixels we mean, now that we define two
   kinds in Annex H.

   Glenn: I have a note to myself to explain that we mean logical
   pixels. I think there may
   ... be one place that you [Nigel] pointed out recently where we
   say display pixels but
   ... we mean logical pixels.
   ... Presentation Context Coordinate Space - under tts:position
   there's an image about
   ... percentage based positioning and a couple of paragraphs
   down it mentions it.
   ... So I need to review that and make sure that is is correct.
   ... I've noted for myself that all layout is done in logical
   pixels.

   Nigel: I think that's worth clarifying.

Meeting close

   Nigel: We're out of time, thank you everyone. For those who are
   going to be present,
   ... see you next week. Final word: please do review TTML2 now
   and raise any issues
   ... sooner rather than later - anyone raising a bunch of issues
   on June 28 is just going
   ... to create upset! [adjourns meeting]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.152 ([18]CVS log)
    $Date: 2017/06/01 16:19:04 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 1 June 2017 16:24:54 UTC