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

On Fri, Dec 6, 2013 at 1:25 AM, Nigel Megitt <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.


>
>  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.


>
>  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.

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.


>
>  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.
>
> ---------------------
>