See also: IRC log
<scribe> scribe: nigel
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!
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]
Revert deprecation of ttp:profile on root element. #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.
Ways to make span background height be lineHeight #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
Issue 0150 inline background height #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
Change itts:fillLineGap to ittp:fillLineGap. #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.
Two value percentage fontSize not fully defined #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.
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]