RE: TTML Agenda for 15/05/13

Yes that sounds fine. If you can have it done in time for tomorrow, so much the better.

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 15 May 2013 22:19
To: Sean Hayes
Cc: Michael Dolan; public-tt
Subject: Re: TTML Agenda for 15/05/13

How about if I edit in place to add an Approach #2, leaving your approach labeled as Approach #1?

On Wed, May 15, 2013 at 3:06 PM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
Feel free to draft a counter proposal, or edit in place.

From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: 15 May 2013 20:54
To: Sean Hayes
Cc: Michael Dolan; public-tt

Subject: Re: TTML Agenda for 15/05/13


On Wed, May 15, 2013 at 1:32 PM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
While the mapping :
<p tts:extent="100px 100px" tts:origin="50px 50px">Some Text</p>

to

<region id="generated12345">
  <tts:style tts:extent="100px 100px"/>
  <tts:style tts:origin="50px 50px"/>
</region>
...
<p region="generated12345">Some Text</p>

Is the general idea, I formulated it in the CP as XSL-FO so that the p would map directly to a block-container/block paired construct:

            <!—- p -->
            <fo:block-container id="generated12345" absolute-position="fixed"
                  left="50px" top="50px" width="300px" height="100px">
              <fo:block>
                <fo:inline>Some Text</fo:inline>
              </fo:block>
            </fo:block-container>

I believe this is legal/correct, as block-container can be a child of block, and the absolute positioning moves it out of the block flow, although I’m not wedded to this approach if someone wants to volunteer to write up a better one.

I think this is the wrong approach, as it introduces unnecessary mapping rules to 9.3.3. It is much better handled in as a strict shortcut to region specification, and taken care of in 9.3.2. There is no benefit in mapping it directly, but there is a negative, meaning you have to recursively (and redundantly) define the formatting semantics of its content.


From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: 15 May 2013 19:58
To: Michael Dolan
Cc: public-tt
Subject: Re: TTML Agenda for 15/05/13


On Wed, May 15, 2013 at 11:59 AM, Michael Dolan <mdolan@newtbt.com<mailto:mdolan@newtbt.com>> wrote:
Some advance thoughts:

1. Proposal 1 (extension to set) is OK with me.

2. Proposal 2 (origin and extent semantics for <p>) - although I am
cautiously supportive of exploring this, I thought we previously agreed that
it is still lacking defined behavior for how text would flow within the
region, including wrap behavior, as well as the behavior of CR, LF and TAB
when content is randomly placed like this.  I think flow examples would be
needed just to better understand the ramifications, as this will be complex.
An alternative might be to define a non-flow region? (Just an idea - the use
cases that this addresses do not generally involve "rollup" captions).  A
minor comment on the first bullet of the "Impact" - the fact that there are
attributes that have no semantic meaning on some elements is a very general
issue and therefore the fact that the XML schema (properly) represents the
permitted syntaxes on <p> is not really relevant or specific to the affected
element and attributes. Suggest it be deleted.

Actually, I don't see any problem with the concept. It is just a shorthand for defining an anonymous region. So it would be treated exactly as if a region had been specified with the indicated origin/extent and an id that is synthesized.

For example,

<p tts:extent="100px 100px" tts:origin="50px 50px">Some Text</p>

maps to

<region id="generated12345">
  <tts:style tts:extent="100px 100px"/>
  <tts:style tts:origin="50px 50px"/>
</region>
...
<p region="generated12345">Some Text</p>

Formatting, CRLF, etc. would have the same presentation semantics as if this latter had been used rather than the shorhand former.

If this is the essence of CP2, I don't have any problems approving it in principle, with the actual words to be worked out in the spec.


3. Proposal 5 - Although we discussed this generally, I don't recall seeing
these details before. I'm not opposed, but it seems like it would be
premature to approve it tomorrow.

Clearly CP5 needs some careful study. Perhaps Sean can go over the essentials of it tomorrow. We know we want to define this mapping, so it is the details we'll have to (eventually) agree upon.


Regards,

        Mike

-----Original Message-----
From: Sean Hayes [mailto:Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>]
Sent: Wednesday, May 15, 2013 10:04 AM
To: 'public-tt@w3.org<mailto:public-tt@w3.org>'
Subject: TTML Agenda for 15/05/13


our teleconference is scheduled with reference to Boston Time, the correct
time of this teleconference in your locale may change. Please check
http://timeanddate.com/worldclock/fixedtime.html?month=05&day=15&year=2013&h

our=10&min=0&sec=0&p1=43

Thursdays 10:00am-11:00am Boston local

 Zakim Bridge +1.617.761.6200<tel:%2B1.617.761.6200>, conference 8865 ("TTML")
IRC: server: irc.w3.org<http://irc.w3.org>, port: 6665, channel: #tt Web gateway to
:http://www.w3.org/2001/01/cgi-irc



Chair: Sean Hayes

Agenda+ Assign Scribe

Agenda+ Proposed updates to charter :
http://www.w3.org/2013/05/timed-text-charter.html


Agenda+ Progress on publication of SE

Agenda+ HTML5 mapping (now as change proposal [1])

Agenda+ Approval of 1.1 Change proposals [2] and [3].

AOB

Tracker (Issues and Actions): http://www.w3.org/AudioVideo/TT/tracker

Profile draft:  http://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10-sdp-us


Change proposals:
[1] http://www.w3.org/wiki/TTML/changeProposal005

[2] http://www.w3.org/wiki/TTML/changeProposal001

[2] http://www.w3.org/wiki/TTML/changeProposal002



TTML Wiki
http://www.w3.org/wiki/TimedText


Second edition draft:

https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10/spec/ttaf1-dfxp.html?content

-type=text/html%3bcharset=utf-8