- From: Andreas Tai <tai@irt.de>
- Date: Thu, 24 May 2012 08:33:40 +0200
- To: public-tt@w3.org
- Message-ID: <4FBDD644.3030203@irt.de>
For the EBU subset of TTML we have to include a change of the padding attribute in the version 1.0 to meet requirements of our target group. As understood a change that adresses Issue 168 (http://www.w3.org/AudioVideo/TT/tracker/issues/168) will be adopted in TTML earliest in 2013. Nevertheless it would be good that the wording in the EBU-TT spec is aligned with an expected change in TTML 1.1. The application of padding to p and span will be specified in the EBU-TT spec as follows: "Padding (or inset) space on all sides of a block area generated by a tt:p element or an inline area generated by a tt:span element. The padding property shall not be inherited." It would be great to hear your opinion. Best regards, Andreas Am 08.05.2012 22:27, schrieb Sean Hayes: > Hmm. I was sure I'd created an issue for this, but apparently not. > > ISSUE-168 <https://www.w3.org/AudioVideo/TT/tracker/issues/168> added > to database > > > ------------------------------------------------------------------------ > *From:* Andreas Tai [tai@irt.de] > *Sent:* 08 May 2012 6:26 PM > *To:* Sean Hayes > *Cc:* Glenn Adams; John Birch; public-tt@w3.org > *Subject:* Re: Padding on tt:p and tt:span elements > > Will there be an entry in the tracker for this? > > In addition I attach an html-example that shows the wished behaviour > and a CSS definition that is similiar to the needed TTML styles. > > Best regards, > > Andreas > > Am 25.04.2012 21:56, schrieb Sean Hayes: >> >> While what you say is true it is very inconvenient from an authoring >> perspective, and if the user can set the font (which is a requirement >> of the FCC rules), then you need the region to be able to adapt. >> Better to use the <p> background which does adapt naturally. You can >> artificially introduce the padding using spans with preserved space, >> however this is a pretty ugly hack. I think it makes sense to allow >> padding on these elements. >> >> *From:*Glenn Adams [mailto:glenn@skynav.com] >> *Sent:* 25 April 2012 17:04 >> *To:* John Birch >> *Cc:* tai@irt.de; public-tt@w3.org >> *Subject:* Re: Padding on tt:p and tt:span elements >> >> On Wed, Apr 25, 2012 at 9:33 AM, John Birch >> <John.Birch@screensystems.tv <mailto:John.Birch@screensystems.tv>> wrote: >> >> You hit the nail on the head. Font size at authoring time is only >> true if font exists at browser... Otherwise substitution means all >> bets are off. >> >> not quite; you can always overestimate the size which permits >> containment without overflow >> >> Best regards, >> John >> >> *From*: Glenn Adams [mailto:glenn@skynav.com >> <mailto:glenn@skynav.com>] >> *Sent*: Wednesday, April 25, 2012 04:00 PM >> *To*: John Birch >> *Cc*: Andreas Tai <tai@irt.de <mailto:tai@irt.de>>; public-tt >> <public-tt@w3.org <mailto:public-tt@w3.org>> >> *Subject*: Re: Padding on tt:p and tt:span elements >> >> On Wed, Apr 25, 2012 at 5:22 AM, John Birch >> <John.Birch@screensystems.tv >> <mailto:John.Birch@screensystems.tv>> wrote: >> >> In TTML as I understand it(as a result of derivation from >> xsl:fo?), there is no possible mechanism that can *set* the >> region size as a result of a calculation of the *rendered* text >> size on the display. In contrast to broadcast practises, in TTML >> the text is fitted inside a predefined region (or overflows / >> clips), rather than the region (growing) fitting the text. >> >> it can, if the size can be determined at authoring time; but that >> will depend on font usage; so you are correct that if the font >> size is unknown, then you may have to overestimate the size, >> e.g., by using em or c length units >> >> *John Birch | Screen Systems | Strategic Partneships Manager* >> >> Main Line : +44 1473 831700 <tel:%2B44%201473%20831700> | Ext : >> 270 | Direct Dial : +44 1473 834532 <tel:%2B44%201473%20834532> >> Mobile : +44 7919 558380 <tel:%2B44%207919%20558380> | Fax : +44 >> 1473 830078 <tel:%2B44%201473%20830078> >> John.Birch@screensystems.tv <mailto:John.Birch@screensystems.tv> >> | www.screensystems.tv <http://www.screensystems.tv> | >> http://twitter.com/ScreenSubtitles >> >> *SysMedia - Now part of Screen* ......a fusion of expertise, a >> combination of World Leading Products >> >> *LAUNCHING SOON! *A new single website incorporating all Screen >> and Sysmedia products. >> >> *Visit us at >> Broadcast Asia, Block 4F3-01, UK Pavillion, Suntec Singapore, >> 19th - 22nd June 2012 * >> >> *P**Before printing, think about the environment* >> >> This message may contain confidential and/or privileged >> information. If you are not the intended recipient you must not >> use, copy, disclose or take any action based on this message or >> any information herein. If you have received this message in >> error, please advise the sender immediately by reply e-mail and >> delete this message. Thank you for your cooperation. Screen >> Subtitling Systems Ltd. Registered in England No. 2596832. >> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, >> Ipswich, Suffolk, IP6 0EQ >> >> ญญ >> > > > -- > ------------------------------------------------ > Andreas Tai > Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH > R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR > Floriansmuehlstrasse 60, D-80939 Munich, Germany > > Phone: +49 89 32399-389 | Fax: +49 89 32399-200 > http:www.irt.de | Email:tai@irt.de > ------------------------------------------------ > > registration court& managing director: > Munich Commercial, RegNo. B 5191 > Dr. Klaus Illgner-Fehns > ------------------------------------------------ -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389 | Fax: +49 89 32399-200 http: www.irt.de | Email: tai@irt.de ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------
Received on Thursday, 24 May 2012 06:35:45 UTC