Re: TTML Agenda for 15/05/13

On Wed, May 15, 2013 at 1:32 PM, Sean Hayes <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]
> *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> 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]
> Sent: Wednesday, May 15, 2013 10:04 AM
> To: '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<http://timeanddate.com/worldclock/fixedtime.html?month=05&day=15&year=2013&hour=10&min=0&sec=0&p1=43>
>
> Thursdays 10:00am-11:00am Boston local
>
>  Zakim Bridge +1.617.761.6200, conference 8865 ("TTML")
> IRC: server: 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<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10/spec/ttaf1-dfxp.html?content-type=text/html%3bcharset=utf-8>
>
> **
> ******
>
>  ** **
>