- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 1 Jun 2017 16:24:21 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D555FDB1.40F26%nigel.megitt@bbc.co.uk>
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