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

On Thu, Dec 12, 2013 at 11:24 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  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> wrote:
>
>
> 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.
>
>
>  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/
>

Since TTML primarily makes use of features whose semantics are defined
elsewhere, it has been standard procedure to adopt solutions to
requirements even when they may exceed the scope of the requirements. This
is considered a good strategy because:

(1) implementations of existing solutions are already available;
(2) for purposes of communication and understanding, as well as reducing
confusion for authors, aligning semantics models is assigned higher
priority than limiting scope to precisely the stated requirements;
(3) when a solution is introduced that exceeds a requirement, it is often
the case that actual use will be made of the additional "excess" portion of
the solution;
(4) for purposes of testing, it is often easier to reuse existing tests
that closely match semantics (rather than subsetting them to meet the
"requirement of the day";


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

Sure, we can always specify semantics beyond either CSS or XSL-FO (or
another formatting model), however, we do so at a certain amount of risk
that needs careful consideration. The risk being:

   - mappings to existing CSS or XSL-FO have to disregard (discard)
   unmappable semantics
   - alternatively, the mapping process becomes more complex, e.g., a TTML
   client may have to perform its own formatting or map otherwise unmappable
   fragments to SVG within HTML;



>
>
>>  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'm not disagreeing with your expression of the problem authors may face in
trying to effectively use padding on span. I do still think that better use
and support for the different Unicode space characters (U+2000 to U+200B)
[1] in combination with padding on span could address the stated
requirement: specifically, one can use ZWSP (U+200B) to ensure word breaks
are marked in content. However, it remains true that a document that relies
on this approach would not have the intended formatting on a presentation
processor that doesn't support padding on span. So it is still not
backwards compatible proof as far as formatting is concerned.

[1] http://www.unicode.org/charts/PDF/U2000.pdf


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

I think we should raise this matter at an appropriate point with the CSS
WG, but we need to document the requirement well enough that they will
understand our problem without getting into TTML specific semantics. Also,
if they don't think that implementers will support a new feature to address
this problem, then it is unlikely they will agree to define a new feature
that satisfies our requirement.



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