Re: Padding on tt:p and tt:span elements

Yes, I think some informative guidance might be very helpful (if it was 
meant that way).

To add a Non breaking Space in the TTML document, e.g.

<span tts:backgroundColor="black" tts:color="white">&#160;A subtitle on 
one line&#160;</span>

is not a solution I would prefer, because it clearly breaks the 
separation of content and layout.

What can be done for a specification that needs to define this 
presentation behaviour is  the following:

To state an normative prose what is defined in the YouView spec:

"Where text with tts:backgroundColor is applied at the span level, the 
filled area shall extend the width of a space character to the left of 
the first rendered character on each line and to the right of the last 
rendered character on each line."

In addition: an informative note how this could be achieved, e.g. with 
option B below - prefixing and suffixing with NBSP by the client(!).

Actually for a specification that reference TTML 1.0 it make no sense to 
apply the tts:padding to a span - unless the fontSize is defined 
directly or indirectly as cell and the metric "c" is allowed for 
padding. The application to a p seems not to be needed anyway because 
this would be the same as the application of padding to the region where 
the p is contained.

Best regards,

Andreas


Am 17.07.2013 11:16, schrieb John Birch:
> A more palatable option might be to suggest this as a (temporary?) 
> implementation strategy... I.e. Specify that padding on a span is 
> allowed and should either be a) ignored or b) interpreted and 
> implemented in the client by prefixing and suffixing the text with 
> NBSP....
>
> J
>
>
> *From*: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
> *Sent*: Wednesday, July 17, 2013 09:50 AM
> *To*: Glenn Adams <glenn@skynav.com>; Andreas Tai <tai@irt.de>
> *Cc*: public-tt <public-tt@w3.org>
> *Subject*: Re: Padding on tt:p and tt:span elements
>
> Agree that adding in spaces would achieve the desired appearance, and 
> might work as a short term fix for distribution purposes, but it is 
> not a good solution (or a solution at all) for archiving and other 
> processing: amending the text content of the TTML in order to fix the 
> appearance mixes two worlds that should ideally stay separate. Hence 
> the request to add padding to spans.
>
>
>
>
> On 16/07/2013 20:45, "Glenn Adams" <glenn@skynav.com 
> <mailto:glenn@skynav.com>> wrote:
>
>
>     On Tue, Jul 16, 2013 at 12:31 PM, Andreas Tai <tai@irt.de
>     <mailto:tai@irt.de>> wrote:
>
>         As a couple of TTML.next issues are discussed at the moment I
>         want to bring up the padding issue again. This is filed as
>         Issue 168.
>
>         Currently it is hard to solve following requirement for
>         background colour fill that is defined in the Youview TTML
>         profile[1]:
>
>         > Where text with tts:backgroundColor is applied at the span
>         level, the filled area shall extend the width of a space
>         character to the left of the first rendered character on each
>         line and to the right of the last rendered character on each
>         line.
>
>
>     One way to achieve this as a work around (in the near term) is to
>     use NBSP, EM SPACE, EN SPACE, THIN SPACE and so on, using
>     tts:wrapOption as needed to prevent line breaks.
>
>
>         If in TTML.next padding could be applied to a span: to what a
>         percentage value would relate to?  In XSL 1.1 and CSS 2.1 it
>         relates to the width of the containing block [2]. So assumed
>         this will be the same definition in TTML, a span would be the
>         child of a p element and a padding value would be specified in
>         percentage for that span than it would be the width of that p
>         element?
>
>
>     Actually, the XSL-FO definition is based on the nearest ancestor
>     reference area, which is the block-container generated by
>     tt:region. So a percentage would be resolved according to the
>     contain region size. When we do map to CSS we will need to
>     translate to non-percentage values in order to avoid the distinct
>     CSS definition.
>
>         This would be very similar to the current definition. In TTML
>         the percentage value for padding is defined as relative to the
>         width and height of the region. As the extent of a p is the
>         same as the extent of the region where it is contained the
>         width of the containing block is effectively the with of the
>         region.
>
>         As the width of the region could vary this seems not a good
>         solution for the requirement defined by the Youview spec.
>
>         The only possible solution to establish a relation between the
>         chosen font and the padding value seems to be the cell metric.
>         To emulate the width of a space the padding value of the start
>         edge for the first span in a line and the padding value for
>         the end edge of the last span in line could be set to 1c
>         (assumed that the font-size is 1c). Is there any more
>         intuitive solution?
>
>
>     Use NBSP. Any any case, 1c doesn't mean 1 EM unless fontSize is
>     defined as 1c.
>
>
>         Best regards,
>
>         Andreas
>
>         [1]
>         https://industry.youview.com/resources/YouView_Core_Technical_Specification_1.0.pdf,
>         page 120, Section 4.4.4.4
>         [2] http://www.w3.org/TR/xsl/#padding-before
>
>
>
>
>         Am 24.05.2012 08 <tel:24.05.2012%2008>:33, schrieb Andreas Tai:
>>         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 <mailto:tai@irt.de>]
>>>         *Sent:* 08 May 2012 6:26 PM
>>>         *To:* Sean Hayes
>>>         *Cc:* Glenn Adams; John Birch; public-tt@w3.org
>>>         <mailto: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 <tel:25.04.2012%2021>: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.
>>>>
>>>>         *John Birch | Strategic Partnerships Manager *|*Screen**
>>>>         *Main Line : +44 1473 831700 | Ext : 270 | Direct Dial :
>>>>         +44 1473 834532
>>>>         Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>>>         John.Birch@screensystems.tv
>>>>         <mailto:John.Birch@screensystems.tv> | www.screensystems.tv
>>>>         <http://www.screensystems.tv> |
>>>>         https://twitter.com/screensystems
>>>>
>>>>         *Visit us at
>>>>         SMPTE conference & exhibition, Stand G35, Sydney Exhibition
>>>>         Centre, Darling Harbour, 23-26th July*
>>>>
>>>>         *P**Before printing, think about the environment*
>>>>
>>>>
>>>>         *From:*Glenn Adams [mailto:glenn@skynav.com]
>>>>         *Sent:* 25 April 2012 17:04
>>>>         *To:* John Birch
>>>>         *Cc:* tai@irt.de <mailto:tai@irt.de>; 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 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  <tel:%2B49%2089%2032399-389>  | Fax:+49 89 32399-200  <tel:%2B49%2089%2032399-200>
>>>         http:www.irt.de  <http://www.irt.de>  | Email:tai@irt.de  <mailto: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  <tel:%2B49%2089%2032399-389>  | Fax:+49 89 32399-200  <tel:%2B49%2089%2032399-200>
>>         http:www.irt.de  <http://www.irt.de>  | Email:tai@irt.de  <mailto: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  <tel:%2B49%2089%2032399-389>  | Fax:+49 89 32399-200  <tel:%2B49%2089%2032399-200>
>         http:www.irt.de  <http://www.irt.de>  | Email:tai@irt.de  <mailto:tai@irt.de>
>         ------------------------------------------------
>
>         registration court&  managing director:
>         Munich Commercial, RegNo. B 5191
>         Dr. Klaus Illgner-Fehns
>         ------------------------------------------------
>
>
> ----------------------------
>
> http://www.bbc.co.uk <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.
>
> ---------------------
>
>
> 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
------------------------------------------------

Received on Wednesday, 17 July 2013 15:00:53 UTC