- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 30 Aug 2018 16:43:20 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <D7ADDCFC.66167%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/2018/08/30-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
30 Aug 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/08/30-tt-irc
Attendees
Present
Glenn, Cyril, Thierry, Pierre, Nigel
Regrets
Andreas
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TTML1
3. [6]TTML2
4. [7]Clarify text combination semantics in a ruby
container context (#978). ttml2#979
5. [8]Remove #textOrientation-sideways-LR and related
semantics (#980). ttml2#981
6. [9]IMSC rh and rw units
7. [10]Meeting close
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: Hi everyone, welcome back after our 2 week break from
meetings.
... For today, we have TTML1 3ED tests, TTML2 actions and
tests, IMSC?
Pierre: If we have time it would be to discuss how to progress
on rh and rw (not urgent).
Nigel: Ok, thank you, let's do that.
Pierre: I can give you an issue: imsc-tests#77.
Nigel: We also have some progress on IMSC vNext Reqs which we
should try to get out of the door if we can.
... On CSS, there's been a bit of progress on content box
sizing to mention if there's time.
... I'm not aware of anything on profile registry.
... Any other specific points to raise or other business?
Pierre: Given we're about 1 month away from scheduled PR
transition, it'd be good to
... look at the TTML2 CR Exit Criteria and check we have
consensus on what they mean.
... It would be too late if we have a disagreement on October
4.
Nigel: OK let's do that in the TTML2 agenda section.
Glenn: I added 2 agenda PRs on TTML2 last night.
Nigel: Thank you, I didn't notice those.
... We'll cover them in TTML2 also.
... Let's cover the agenda in order.
TTML1
Nigel: We have 3ED tests to review, thank you Pierre -
[13]https://github.com/w3c/ttml1/pull/361
... I haven't managed to pick this up again since returning
from vacation. Anything to discuss on this?
[13] https://github.com/w3c/ttml1/pull/361
group: [silence]
Nigel: Okay let's review as normal on GitHub.
Glenn: On these tests, Pierre, do we have implementation
support for them all at this point?
... Is there any idea that we won't be able to produce
implementation for ...
Pierre: The only one is 2-value relative font size, which
imsc.js won't be able to demonstrate
... for presentation.
Glenn: Okay TTPE can demonstrate that. That should be no
problem.
Nigel: Is that only one implementation then?
Pierre: One validator and one presentation engine.
Nigel: Do we have an independent validator?
Pierre: Whatever validates TTML2 should validate those by
extension. Whatever we do for
... TTML2 will have to work with this, by definition.
Nigel: Okay we'll be needing two independent implementations
for that test.
Pierre: Again, whatever scheme we come up with for TTML2 will
apply. I'd focus on solving
... the TTML2 challenge then we can talk about this.
Glenn: I haven't looked at the TTML1 3ED CR Exit criteria - is
it the same as TTML2?
Pierre: No, slightly simpler, just 2 independent
implementations.
Nigel: The whole profile validation semantic test requirement
doesn't apply.
Glenn: Okay, thanks.
Pierre: By the way Glenn have you run TTXV on the files?
Glenn: I haven't had a chance to use it to validate them.
Pierre: I'll run them through it now.
Nigel: Please could you add a comment to the pull request when
you've done that?
Pierre: Yep.
Nigel: Thank you
TTML2
action-443?
<trackbot> action-443 -- Glenn Adams to Prepare a document
showing mapping arib ruby extension features to ttml2 for use
as a liaison document to arib. -- due 2018-08-09 -- OPEN
<trackbot>
[14]https://www.w3.org/AudioVideo/TT/tracker/actions/443
[14] https://www.w3.org/AudioVideo/TT/tracker/actions/443
Glenn: Nothing new to report there right now.
Nigel: Thank you Glenn for your note about completing the
validation tests.
... I guess that means folk can review the validation tests and
we are moving ahead with
... presentation tests?
Glenn: I first populated tests related to features involved in
IMSC 1.1.
Nigel: Presentation tests?
Glenn: Yes. With the exception of #content-profiles I've
already populated presentation
... tests for all the features in IMSC1.1, and for each
presentation test I am also including
... a ZIP file that contains the output from TTPE to give a
quasi-reference content to look at
... for visual comparison. I will be adding some information to
the README to describe that
... information more over the next few weeks but it's basically
the output from TTPE which
... consists of one or more SVG files representing the output
image and a manifest file which
... associates time for a particular frame that the SVG
represents. Those are being populated
... together with the tests. Beyond those I have now populated
about 100 presentation tests
... altogether covering most of the new style features and I'm
working through those. At this
... point I'm only aware of one implementation working on
satisfying the non-IMSC 1.1
... tests for presentation, which is TTPE, so that work is
progressing rapidly. I'm confident
... we will have all the remaining tests in place in time for
Sep 26 ahead of PR.
Nigel: We are still working on an implementation for the audio
features, called "adhere" and
... I have begun working on presentation tests for the audio
style features.
... Is that a duplication of effort?
Glenn: Thanks for mentioning that, no, we're not doing those
features, nor disparity and luminanceGain
... which imsc.js is doing. We're depending on adhere to
satisfy the audio features.
Nigel: And producing tests also?
Glenn: Yes, if you can supply tests that would be great.
Nigel: I'll do that.
... Thank you for the status update.
... Let's cover the requested discussion of exit criteria and
then the pull requests
... marked for agenda.
... [reads the TTML2 CR exit criteria]
... Pierre you wanted to clarify the interpretation?
Pierre: Thanks. Today based on Glenn's report it looks like we
will have one presentation
... processor for every feature, combining the BBC work,
imsc.js and TTPE. Correct me if I'm
... wrong but we're good on the presentation side.
Glenn: Modulo one of the opened issues.
Pierre: Now, validation. My understanding, for someone to
disagree with or not, is that
... TTV cannot be used because it is not independent of TTPE,
and further, IRT will be offering
... IRT SubCheck as an independent validating implementation,
and that will cover all of
... IMSC 1.1. And TTV can be used for audio features because
TTPE does not implement
... those, similarly for luminanceGain and disparity. That
leaves the remaining TTML2
... features. How do we deal with those? Do we need an
independent implementation?
... What are the requirements of such an implementation?
Nigel: My answer would be yes, we do need an independent
implementation, and the
... requirement for it would be that it is a transformation
processor.
... First point: every feature needs at least 2 independent
implementations.
... Second point: if there are any features that do not define
both transformation and
... presentation semantics, then TTV or TTPE can do one of
those, and another independent
... implementation is needed for one of those functions.
... Do we have any features that do not define both
transformation and presentation semantics?
Glenn: The transformation output is application dependent.
Nigel: That's different - it's about what the spec defines.
Pierre: linebreak-uax14 is an exception.
Nigel: We can exclude that because it's a TTML1 feature.
Glenn: The #speech feature is dependent on the processor
support only.
Nigel: Right, that has no transformation semantic.
... In that case for #speech, both implementations must be
presentation processors and
... validation is not applicable.
... For all the rest, of the new TTML2 features, we do need an
independent implementation
... that either validates or presents the features that are not
covered by TTPE, since all
... the validation tests are passed by TTV already.
Glenn: I didn't add a column for "both validating and
presenting" processors.
Nigel: I don't think you need to.
Glenn: I consider TTV to be a transformation processor whose
output indicates validity.
Nigel: I think that's right.
Glenn: It can be used independently of TTPE or as a
pre-processor.
Nigel: Yes, but that independent running does not mean they are
independent implementations.
Glenn: I wanted to mention that. The Charter and the Process
don't define independence,
... we should let the Director decide.
... In that vein, in the current Google sheets document that
we're populating, I've put a couple
... of columns to count implementations. There's a #v column
that counts validation implementations.
... There's a #p column that counts presentation
implementations.
... Then #t is the total of those. It does not try to assess
independence.
Nigel: I don't think that's correct that there's no definition
of indepedence.
Glenn: I read the Process carefully last night and it doesn't
say what is meant.
Nigel: Thierry, do you have a view on this?
Thierry: As usual, you have to make your case to the Director.
... There is not a strict policy in W3C documents that says.
Glenn: Interestingly one of the questions is "are there
implementations created by people
... other than the authors of the specification?" !
... My opinion is we should count what we think are
implementations and present that to
... the Director.
Pierre: We can't wait until Oct 4 to find that assumption is
wrong.
... We should check tomorrow with the Director.
Glenn: I'm not arguing we should say TTV and TTPE are
independent. I'm just saying we
... should present the information. If we want to present
background information about
... the organisations that created the implementations we could
do that. I'm just pointing
... out that there's no definition.
Nigel: What about the Charter?
Cyril: It says "n order to advance to Proposed Recommendation,
each specification is expected to have at least two independent
implementations of each of feature defined in the
specification."
... I guess this was agreed by the Director.
Nigel: Yes, and it links back to the Process document for the
section on independence.
... I raised an issue with the Process group about this, which
is closed at the moment:
[15]define "independent" #167
[15] https://github.com/w3c/w3process/issues/167
Thierry: This has been ongoing for years. My personal view
which the Director usually
... takes also is that if the implementations share code they
are not independent.
Glenn: In the case of TTV and TTPE for example, one option for
TTPE is to ingest the ISD
... documents produced by TTX, so it doesn't need to start with
the TTML document which
... is then ingested through the validating process of TTV as a
pre-processing module.
... It can take the ISD documents from TTV or TTX or somewhere
else as input. In that sense
... one could potentially make the argument that they do not
share the same code but it is
... a processing option.
... There is another question which is what it takes to satisfy
Nigel's interpretation for the
... transformation aspects.
Nigel: Thanks. There are two things I'd like to comment on:
... 1. Transformation requirements.
... 2. The case I will need to make to the Director that we
have satisfied the exit criteria.
... Taking them in order...
... Transformation requirements - the implementation needs to
do some kind of
... transformation as per the feature designator's definition
of the transformation semantics.
... Take #bpd for example. The feature designator refers to the
tts:bpd attribute, but
... the spec does not define any transformation semantics. So
in that case merely noting
... the existence of tts:bpd in a document would satisfy the
transformation requirement.
... An implementation that gave a true/false or even a count of
tts:bpd instances in the input
... document instance would work for me.
Glenn: Another example: One type of transformation is the
identity transformation. In our
... case outputting the same document as was input, say, but
stripping out all foreign
... vocabulary, would be an example. Another would be, instead
of counting #bpds, count
... validities or invalidities, otherwise have no output.
... We discussed this with TTML1 and tried not to define any
transformation processing
... output so it would be open-ended, which leads a lot of
latitude.
Nigel: Yes, and I'm happy with any of the above, to answer your
question Glenn.
Pierre: There's an XML schema defined - would a schema
transformation fall into that
... category?
Nigel: What do you mean by a schema transformation?
Pierre: Like schema validation.
Glenn: I think if you have a shell script that runs a schema
validation tool that uses as its
... input a TTML2 document and the set of official schemas that
we publish along with the
... spec, even though they're not normative, would that satisfy
the definition of a transformation
... processor, the output of which is "yes it passes the
schemas" or "no it does not"? I think
... that's a reasonable transformation processor in our terms.
Nigel: I'd be happy with that.
... Hopefully that's clarified the minimum requirements for a
transformation processor.
... Moving to the second part, what would I be happy to present
to the Director as
... being independent implementations?
... My take on this is that the most valuable interpretation of
the Process here is that the
... implementations are produced either by two separate
organisations, or, if they're
... produced by the same organisation, that any queries
regarding implementation were
... dealt with in the scope of the WG.
... Certainly I would not expect them to share code in general,
but of course almost every
... piece of software written in any one language shares some
code with any other code
... written in the same language, so at some point in the stack
that can't always be true.
... Pierre, does that clarify your query for raising this?
Pierre: Yes, I think so. Let's take a concrete example -
#letterSpacing. If the two implementatinos
... were a) TTPE and b) a script that runs the XML Schemas
against all the valid and invalid
... tests, that would be sufficient in your mind?
Nigel: Yes, because although as it happens Glenn mainly wrote
the schemas and also
... wrote TTPE, the schema work came via the WG and the
implementation code executing
... those schemas would be independent also. So I'd be happy to
describe those as
... independent.
Pierre: Okay, so, Thierry, any thoughts on this, reactions?
Thierry: No, I think that's how we should proceed.
Pierre: This has the potential of really saving an awful lot of
time but I think it would be
... really good to confirm with the Director that this would be
acceptable before Oct 4.
Thierry: That's what transition requests are about.
Pierre: If this doesn't work, we don't have time to come up
with an alternative. Is it
... possible to check a priori if this is a valid approach?
Glenn: We can't have 2 transition requests.
Nigel: We can do something here, which is to inform the
Director that this is our minimum
... baseline for meeting the CR exit criteria and point out the
time constraints, and offer him
... the opportunity to tell us up front if that seems
problematic with him.
Cyril: I approve of this approach to check we are going in the
right direction.
Nigel: Thierry, is this best coming from you or me?
Thierry: I would prefer the Chair to do it.
Glenn: That was going to be my suggestion.
Nigel: Okay, I'll take that as an action.
... I'll send it to an appropriately small group of people.
Glenn: By the way, getting the Director's approval in that
regard, or giving them a chance
... to input, doesn't mean that during the PR process we will
not receive objections from
... members about that process, so that's always a risk that we
have to face.
Nigel: Good point.
Glenn: Before we go to the issues, I have a separate comment.
... I have been describing the validation portion of the test
suite in a particular way in terms
... of what I believe it means to pass the test suite. I want
to mention that and see what
... the group thinks. I've been describing that if the
implementation does not report a false
... negative for any of the valid tests then it passes the test
suite. So if it does not
... produce an error for any of the invalid tests then it could
still pass. We do not set a bar
... for invalidity, but we have a note that not every
implementation of a validator need
... detect all potential invalidities. We can not force a
validation implementation to check
... every invalidity. It happens that TTV does detect and
report every invalidity. Similarly it
... does not report any errors in the valid tests. But another
implementation will very likely
... not detect all invalidities because the schemas are overly
broad, for example they use
... xs:string for complex types. The schemas by themselves as
we publish them will not
... detect all of the things that we call invalid. I want to
check we have consensus on that
... interpretation, somewhat separate from the previous
conversation.
Pierre: It is related, because it means schema validation will
not report some of the
... invalid files as invalid.
Glenn: If we're reporting it as a transformation processor and
are relying on TTV to satisfy
... the requirement for a validation processor then we don't
need to rely on those for
... validation tests because the way the exit criteria are
written the validation semantics
... can be reported for either of the implementations.
Pierre: Right, what you're saying is that for the purpose of
transformation processing
... we can only run the schemas against the valid tests.
Glenn: Yes, or you could run them only on the presentation
tests or only on the IMSC 1.1 tests.
Nigel: That (IMSC 1.1 test) wouldn't quite work, we need to get
coverage of all the features.
Glenn: Right, if you ran it against all of the valid tests
under the validation test suites and
... all of the valid presentation tests then that would cover
all the features.
Nigel: Sounds reasonable.
... I don't think there's any harm in running against the
invalid tests either - noting that
... the output is not scrutinised in detail.
Glenn: I agree.
Nigel: That's right, it would count as transformation but not
necessarily validation.
... Playing with ideas about tranformation processors, you
could write an XQuery that
... outputs the locations of all the syntax referenced by a
feature.
Glenn: Some of those are maybe challenging if they involve
non-local context.
Nigel: That's true.
... Back to your question Glenn, I've not heard any objection
to your definition of "pass"
... when it comes to validation, but thank you for highlighting
it - if anyone wants to comment
... on this offline then please feel free to raise it on the
reflector.
Glenn: Just for the record, ยง5.3.1.2 in the current spec has a
note that I was referring to.
... It sets the expectations about detecting invalidities and
reporting false positives.
Clarify text combination semantics in a ruby container context
(#978). ttml2#979
github: [16]https://github.com/w3c/ttml2/pull/979
[16] https://github.com/w3c/ttml2/pull/979
Glenn: For this item, when I was ingesting the IMSC 1.1 tests
into the TTML2 test suite
... I ran across a case when tts:textCombine was used inside a
ruby context, in the base,
... which apparently IMSC.js maps to CSS and one
implementation, Firefox, does something
... sensible with that. However nowhere in TTML2 did we mention
the use of textCombine
... in a ruby context or vice versa - not in textCombine or
ruby sections. In CSS's own
... version of text-combine and ruby you will not find it there
either. My contention is that
... that usage is not defined in TTML2. Certainly I did not
consider it when I wrote those
... sections. I had no use case for it at that time. I want to
add an informative note in this PR
... that this usage is not defined in this edition. We can't
add normative text. I want to ward
... off readers interpreting the current lack of language as
carte blanche for using that and
... expecting some output that works like Firefox. However
Pierre thinks we shouldn't do
... anything at this time. That is an option. I stand by the
content of the note, factually.
Nigel: I haven't caught up with this yet and don't have a view.
Glenn: In the pull request it is an editorial change, by the
way.
Pierre: I think in fact the semantics are defined today.
Glenn: We have a factual dispute over this.
Pierre: That's one point of dispute. Another is that the
specific example used in the IMSC 1.1
... test suite actually came from an implementor of Japanese
subtitle and caption products
... so it might be a used test case. Another data point is that
this really deserves more
... discussions and we don't have that time so I'm not
objecting to that issue being resolved
... at some point but I am objecting to trying to solve it
before PR.
... The note proposed is misleading because I think it is well
defined. It is implemented in
... at least one implementation, for what its worth.
Glenn: I assert that it is not defined. Others opinions can be
various. I assert that it is not
... defined in CSS either. The fact that one implementation has
done something does not
... mean that it is sanctioned by CSS. It is not supported by
Safari or Chrome, I haven't tested
... with Edge. The intent of the note was not to resolve the
larger issue of how to define it
... semantically. I agree that needs further treatment and it
is not appropriate to address that
... at this time. There's nothing wrong with putting a note in
that is informative to say it
... is not sufficiently well defined. In fact it is
implementation dependent. I view this as almost
... the same as putting extent or origin on p or div. Some
implementers chose to read between
... the lines and implement some interpretation. We pointed out
it was undefined by the spec.
... I view this as in exactly the same category. The syntactic
possibility does not imply that
... we have defined it.
Pierre: It is different because in that case it was clear that
extent and origin do not apply
... to div and p. In this case the two things are independent.
For example nowhere does it
... say that italics are allowed in a base, but that's correct
I guess.
Nigel: I'm hearing two views:
... 1. Do not add the note.
... 2. We should add the note but it's okay not to.
... In that case we should not add the note.
Glenn: Okay, I can accept that, but may say I told you so
later.
Pierre: I think we should record this on a thread and allow
implementers to work out what
... to do based on that discussion.
Glenn: I pointed out an inconsistency with rubyAlign.
Pierre: Right, so that issue will not be resolved so an
implementer can see it.
Glenn: I will close it and mark as TTML.next.
Pierre: I don't agree with that. It should remain open so
implementers can look at the
... open issues and see that and decide to get involved or
tread carefully. I think we should
... keep it open and change the milestone to 2nd Ed.
Glenn: I have avoided doing that. It's my intention, as soon as
we have published 1st Ed,
... to resurrect those issues and mark them as 2nd Ed.
Pierre: I move that we open them and set the milestone. I think
it was wrong to do that.
... You don't close issues in backlog.
Glenn: That's what we've done. It's a process that works for
me.
Pierre: Yes but it doesn't encourage people to get involved or
warn implementers.
Glenn: I want to avoid giving the impression that there are
unresolved 1st Ed issues.
Pierre: That's why there's a milestone. That's how bug trackers
work.
Nigel: I support the proposal to open them. We can use
milestones for filtering and I am
... not concerned about revealing open issues to the Director
when they're appropriately
... labelled with a milestone.
Glenn: Okay I can do that, I will reopen all the issues marked
ttml.next and assign them
... to a 2nd ed milestone which I will create.
... It doesn't exist yet.
... I'll mark this issue as 2nd Ed and close the pull request
without merging.
Pierre: There are 2 distinct milestones, TTML2 vnext and 2nd
Ed.
Glenn: They're the same in my view.
Pierre: It's fair sometimes to set no milestone for backlog
issues, in other cases we as a
... group can have scheduled them for a particular edition.
Nigel: I think that will work, taking the point that we could
be more precise about the
... target for resolution.
... I think I've identified consensus to close this pull
request and move the issue to 2nd Ed.
... Any objections?
group: [silence]
RESOLUTION: Close this pull request without merging, and move
the issue to 2nd Edition milestone.
Remove #textOrientation-sideways-LR and related semantics (#980).
ttml2#981
github: [17]https://github.com/w3c/ttml2/pull/981
[17] https://github.com/w3c/ttml2/pull/981
Glenn: Summary here is that sideways-left is not well defined
and problematic because
... in our top to bottom inline progression direction vertical
writing directions, if you turn
... English text on the side to the left, then the first letter
of the sentence appears at the
... bottom of the screen and proceeds from bottom to top. The
alternative is to do them
... top to bottom and have a partial mirror image of the text
vertically, which would be
... hard to read. When I reviewed CSS writing modes level 3 and
UTR50 the conclusion I
... reached is that sideways-left is not well defined. I could
implement it but it wouldn't
... make any sense and it would be a waste of effort. If I
implemented it so it starts at the
... bottom and goes to the top then it contradicts the writing
mode definition, without
... introducing a new bottom to top writing mode. This is
marked as at risk so my response
... is to remove this and improve the consistency with CSS.
It's substantive because it takes
... out both sideways-left and sideways-right, leaving mixed,
upright and sideways, where
... sideways always means clockwise, which matches CSS. If we
are going to make this
... substantive change we have to do it under the rubrick of
changing or removing an at
... risk feature. I need someone to review it.
... TTPE is not going to implement it so at the end we will end
up with a red box in the
... implementation matrix.
Nigel: Thank you for raising this, and for inviting @r12a to
review it. I'd be interested to
... hear his comments.
... I can't recall how this got in to our spec.
Glenn: It was in a previous version of a CSS spec but was
removed, probably because it
... doesn't make any sense for top to bottom layout.
Pierre: Digital Cinema implementations support left and right
rotation, but that does not
... mean it is used. I'm not objecting to the removal, just
adding a data point as to why we
... may have ended up with this.
Glenn: That's fired a neuron in my mind, so it's probably the
case.
Nigel: I see Pierre just approved it. We have time to let this
pull request run its course in
... terms of review so I suggest we allow that.
SUMMARY: Pull request review to continue.
IMSC rh and rw units
Pierre: Raising awareness that we have to make progress on
this. The feature is a mix-in
... in TTML2, so by permitting it in IMSC 1.1 we've permitted
it everywhere, which has
... surprised some folks. Since Nigel and Cyril were the
proponents I'd like your view on
... where it is really useful. It is an at risk feature in the
CR so we have the opportunity to
... make changes.
github: [18]https://github.com/w3c/imsc-tests/issues/77
[18] https://github.com/w3c/imsc-tests/issues/77
Pierre: #77 itself can be fixed by removing the test because
the test is invalid per the spec.
... This brings up the bigger issue of what rw and rh should
apply to. I had an action to
... raise an issue, but I need Nigel's and Cyril's input about
what they are useful for, then
... I can raise the issue. I wouldn't be surprised if others
have an opinion, but this would be
... a good place to start.
Cyril: I think I explained our use case which was related to
anamorphic fonts.
Pierre: That helps.
Cyril: We have found a workaround to using anamorphic fonts in
IMSC so I don't think
... we need rw and rh any more.
Nigel: Not at all?
Cyril: Not at all.
Nigel: I think I also stated the main motivation, which was to
avoid the confusion seen in
... real world scenarios when specifying font size, by allowing
an "absolute relative" size
... to be defined, i.e. rw or rh. There are implications there
about which lengths would
... need to support those units, but I'm not averse to
constraining their use to make
... implementation more straightforward.
... I think the big question is if rw units are needed in
vertical contexts and rh units in
... horizontal contexts, and I don't have any concrete examples
where they would be needed.
... However for vertical writing modes, it would make sense to
use rw units for font size.
... I sense that it might add complexity though, rather than
removing it!
Pierre: It's implemented completely in imsc.js.
Glenn: TTPE supports use of rw and rh in any context that
supports that length.
Nigel: Okay, it's at risk but also implemented twice. Why do we
need an issue for it?
Pierre: tts:position specifically allows rw and rh but ...
[checks the spec]
... ... tts:origin does not allow it.
Nigel: That's right.
Pierre: So it's weird but not fatal.
... Basically, rw and rh are allowed everywhere but origin, and
a few other exceptions like
... ebutts:linePadding. Anyway it's weird but...
Nigel: It seems like no action is needed?
Pierre: We could add an issue in the backlog to say root
container relative units are not
... permitted on origin.
Nigel: I think that's correct and as it should be, because
origin and position are not both
... permitted, and if someone wants to use origin for backwards
compatibility then allowing
... rw and rh units on them would be even more weird. I think
no change is needed.
Pierre: The other thing we probably want to do, under position,
if you use rh in a horizontal
... context you can get root container regions that are too
big. That we could specifically
... prohibit in tts:position to avoid people getting into
trouble. Or note that if they do that
... then they better set aspect ratio.
Nigel: I agree that's a practical issue that we should raise.
Pierre: It applies to extent also.
Nigel: Yes it's worth warning about. We already prohibit
regions outside the root container region.
Pierre: The question is if we should syntactically prohibit it.
Nigel: Yes that's an issue to raise.
Pierre: Thanks for working through that, I'll raise it as a
real issue.
Nigel: Great, thank you.
SUMMARY: Raise an issue about syntactic prohibition of rw and
rh on extent and position
Meeting close
Nigel: Thanks for your time today everyone. [adjourns meeting]
... Postscript: I forgot to thank Thierry for getting the
updated CRs published since the
... last meeting. Thank you Thierry!
Summary of Action Items
Summary of Resolutions
1. [19]Close this pull request without merging, and move the
issue to 2nd Edition milestone.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [20]scribe.perl version
1.152 ([21]CVS log)
$Date: 2018/08/30 16:40:42 $
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[21] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 30 August 2018 16:43:47 UTC