Timed Text Working Group Teleconference

<scribe> scribe: nigel

This meeting

Nigel: We have an IMSC PR to review today, and the IMSC 1.x WD for review. For TTML we don't have the right people here to cover the focus topics. AOB?

group: No AOB.

glenn: I'd like to discuss the text orientation questions raised recently on TTML.

IMSC

Nigel: We have 2 open pull requests, and 5 open issues.

-> https://github.com/w3c/imsc/pull/214

-> https://rawgit.com/w3c/imsc1/issue-211-activeArea-by-pos/imsc1/spec/ttml-ww-profiles.html#ittp-activeArea

-> https://www.w3.org/TR/css3-background/#background-position

Pierre: I prefer to use the mathematical definition normatively instead of the text.

Nigel: [edits] OK that should be there now.

Pierre: Works for me. So now as long as x and y and width and height are between 0 and 100%,
... the right and bottom edges cannot be greater than 100%.
... I'm happy for you to merge that, noting that the term Active Area needs to be changed
... to use the defined term.

Nigel: Ok I'll do that after the meeting.

-> https://github.com/w3c/imsc/pull/209

Pierre: You can merge this.

Nigel: You can do it as Editor!

Pierre: OK, merging.
... You'll have to adjust your PR also Nigel.

Nigel: OK will do. Thanks.

-> https://github.com/w3c/imsc/issues/213

Nigel: I think this actually originates in TTML1, where the metadata element mentions
... elements in non-TT namespaces, but no other element does, so it is unclear if foreign
... namespace content is permitted anywhere or just in metadata.

Glenn: Fixing this in TTML1 would be a challenge because it will affect conformance language.

Pierre: The question for IMSC is do we proceed with the IMSC WD update without resolving this issue?

Nigel: (notes that having this discussion is tricky without Mike who raised the issue)

Glenn: The definition of content conformance does not apply any particular kind of processing. For example it does not say that subsequent processing steps must use the result of the abstract document instance.
... If it said that processing must do something based on it then the foreign namespace elements would be pruned first.
... I think this is largely an implementation issue, in practice.
... For example TTML1 §3.2.1 bullet 3 requires non-rejection and non-abortion of the processing if an implied feature is present.

Nigel: The key question is what we do for IMSC. It feels like a TTML issue mainly.

Glenn: I could see an informative note helping under generic processor conformance in TTML1 §3.2.

Pierre: When an element is pruned then all its children are too?

Glenn: Yes, you wouldn't reparent its children.

Pierre: If we're agreed on the end result that foreign namespace elements do not render
... documents non-conformant then I think we can defer that, either in TTML1 or in IMSC1.0.1,
... the latter of which I would prefer not to do.
... The main thing is are we all agreed?

Glenn: The converse is that we would have to say that foreign namespace content is part of
... the validity assessment process.
... I think the note we need to add is that pruned content for validity assessment does not need
... to remain pruned for other onward processes.

Pierre: We should check that everyone is agreed on this.

Nigel: I'm happy to add a note on the issue and highlight this question to the reflector.
... I would particularly like Andreas's view here.

Pierre: If we are all agreed then I think we're safe to defer this and go ahead with a WD for
... Wide Review.

Glenn: Are we going to change the version to 1.1 before publishing the next WD?

Nigel: I'm not sure if it is better to do it earlier or later. Thierry?

Thierry: I have to check this.

Pierre: I recall Andreas and Mike really liking 1.0.1.

Glenn: I think we should put it to the group and not make a change until we have consensus.
... It's worth having Thierry checking on what's possible here.

Nigel: I can ask Mike and Andreas if they would object going to 1.1.

Thierry: Ok let me investigate these two issues, the version number change and if we can add a redirect from 1.0.1 to 1.1.

Pierre: I don't consider it a blocker for going to Wide Review.

Nigel: Re issue #212 I don't think that should hold us up and I'm still looking at the practical issues.

Pierre: Definitely it should not hold us up as it is informative only.

Nigel: Agreed.
... That's closed off all the IMSC 1.0.1 issues that are urgent.

TTML

Glenn: I wanted to discuss text orientation issues.

Pierre: I noticed some differences in implementation between CSS and XSL-FO and I wanted
... to know if the default for XSL-FO applies. Then what is the mapping of that default
... 'vertical' to CSS?

Glenn: In the current draft of CSS3 Writing Mode it talks about the SVG property text-orientation
... which was inherited from XSL-FO.

Pierre: I saw that, unfortunately they are marked for removal.

Glenn: Right, when I started on TTML2 when I got to text orientation and combining I
... ignored the previous work on XSL-FO completely and basically wrote in what was in an
... early draft of the CSS writing modes on this matter. It has changed in CSS3 drafts.
... My question at this point, is regarding direction in the context of text orientation.
... Obviously that only applies in vertical writing modes, ok?

Pierre: Of course.

Glenn: So that then implies that say Hebrew and Arabic in upright are left to right which seems to make no sense.

Nigel: [scribe misses complex details]

Pierre: Here's a stupid question. In XSL-FO the default is "auto" and that says that full width
... latin text is set with an orientation of 0º. For Arabic and Hebrew "latin" does not apply and it
... is not full width either so what is the orientation?

Glenn: Full width only applies to Japanese and Chinese where latin characters are made larger

<pal> - "glyph-orientation-vertical: auto" means "Fullwidth ideographic and

<pal> fullwidth Latin text (excluding ideographic punctuation) will be set

<pal> with a glyph-orientation of 0-degrees."

Glenn: to make them closer to the ideographic character bounds.
... There's a special Unicode code block for full width Latin.
... If you wrote normal ASCII characters that would not be 0º.

Pierre: So they would be rotated?

Glenn: Correct they would be sideways right.

Pierre: That solves my problem because "auto" maps 99% of the time to "mixed" in CSS.
... And that also means that the IRT test vectors are incorrect. Glenn, could you point out the
... difference between full width Latin and ASCII no the thread?

Glenn: Sure.

Pierre: Thank you.
... By the way does it say in TTML1 that XSL-FO defaults apply?

Glenn: No it does not but that's a reasonable interpretation. We never put it in the text.

Pierre: Okay.

Nigel: Which issue is that?

Glenn: It was an offline conversation.

Pierre: This needs more conversation before we decide it is an issue.

Nigel: Thanks everyone [adjourns meeting]