Re: Issue-286: application of padding to p etc

I appreciate that you've returned to the origin of this thread to try to clarify and bring things to a close. I've started a separate thread regarding the process issue this throws up and a potential resolution, titled "New feature requests - working group process".

Comments on this particular thread inline below:

On 11/12/2013 19:03, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


On Fri, Dec 6, 2013 at 1:25 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:

Hi Glenn,

I've had a look at your edit that added padding to content elements and I don't believe that this contradicts the usage defined by EBU-TT-D in Issue-286 as written. However we need to describe exactly what padding means when applied to body, div and span, assuming the EBU proposal for the definition on p carries.

Actually, we don't (need to describe exactly what happens). We only need to map it to XSL-FO or CSS in the mapping section. In general we very much try to not paraphrase or rewrite formatting semantics when we simply wish to make use of the underlying XSL-FO or CSS semantics, which is the case here.

Understood. However in verifying that the solution meets (or even exceeds) the requirements we do need to play it through. In this case the proposed solution creates functionality that doesn't have a requirement based in Issue-286, at least not intentionally, and goes beyond R306 in [1], which states that padding only needs to apply to inline vocabulary, and not block vocabulary. Apologies in advance if that has been superseded by a later change proposal that I haven't caught up with.

[1]  http://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/




body: Since tts:padding is not inheritable and body can not contain content (i.e. what's in the spec as Inline.class)  I'm not sure how it would ever be applied.

Body contains content. Every top-level div constitutes the content of body.


div: Could apply to the set of rendered lines within the div, taken as a single rectangle? This is subtly different from padding on region, which doesn't take into account the width of the rendered lines at all, so I can see it being useful.

Not correct. The CSS semantics apply.


p: as per proposal, applies separately to each rendered line within the p.

No. It applies to each each block area generated by p. The CSS semantics apply.

Agreed we should not diverge from CSS semantics when they're already defined. What's required here may be a behaviour that we need to specify independently of CSS if CSS does not support it.


span: applies to the contained text within the span. Adds to or overrides p-based tts:padding values? Either way this is the most problematic one: the padding creates spacing that is normally created using a spacing text character, which gives the author a no-win problem: either create spans with padding to make spacing correct, and remove space characters from text, or have unwanted extra spacing, dependent on line wrapping. The cost of removing space characters from the text is that meaning is removed – some processors might for example pre-process by removing all formatting (e.g. for indexing), leading to weird compound words where the space has been removed.

The CSS semantics apply. We need say nothing else, though we could provide non-normative, usage notes for readers if needed.

We should not simply apply semantics defined elsewhere without considering the impact on document authors, document processors and users of the rendered output. That consideration may result in a need to change the way the feature is specified or add an informative usage note. My description of the problem is intended to demonstrate that in this case the impact is such that the feature should be specified in a different way.

I think the problem we are having in this thread is that you don't appear to be familiar with the CSS (or XSL-FO) formatting models, and are attempting to interpret TTML style properties without making reference to these models. We have attempted to avoid doing the latter except only in those cases where we wish to diverge from those models. There is nothing in tts:padding that requires that we diverge.

I certainly have much to learn however I respectfully disagree that this is the root of the problem here. See alternate thread referenced above.


Kind regards,

Nigel




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

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.

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