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.

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

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.

---------------------