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

A simple observation…

It should not IMHO be necessary to modify the content in order to effect a specific presentation of that content. That is (again IMHO) a kludge.
Separation of style and content is a secondary requirement and has clearly been achieved in the current TTML specification.

Best regards,
John

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
BVE, Excel London, 25-27 February 2014, Stand M15

P Before printing, think about the environment

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 06 December 2013 18:34
To: Nigel Megitt
Cc: Timed Text Working Group
Subject: Re: Issue-286: application of padding to p etc


On Fri, Dec 6, 2013 at 10:52 PM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
On 05/12/2013 23:25, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:

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.

yes, body contains content, in fact, all content; body maps to fo:block in XSL-FO and will map to an outer div in HTML

Which rendered text would the padding apply to, given that the only content that body can contain is zero or more divs, and divs have a padding attribute of their own, which is not inheritable?

not related to inheritance, each generated block area (box) has its own padding; think of it as a set of nested blocks, each with separate padding:

body padding
  div1 padding
    div1.1 padding
      p1 padding


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.

again, the XSL-FO (=CSS) model applies; padding applies to the block areas (boxes) generated by div

Is that different in effect from the box tightly surrounding all the (i.e. not "each of the…") rendered lines generated from content contained in the div?

not sure what you mean by the box; each of body, div.outer ... div.inner, p generate block areas (boxes), and each has independent padding; see diagram at [1]; the body has its own padding, then each of its div children generate areas placed into the body's content rectangle, where each div has its own padding

[1] http://www.w3.org/TR/2006/REC-xsl11-20061205/#area-intro

e.g. in the following example, there would be 175px of padding to the left of FIRST LINE with respect to the left edge of the region

<region xml:id="r1" tts:padding="100px"/>
...
<body tts:padding="5px" region="r1">
  <div tts:padding="10px">
    <div tts:padding="20px">
      <p tts:padding="40px">FIRST LINE</p>
    </div>
  </div>
</div>

Just want to double check that we have the same understanding on this one. Also that it's not in effect identical to padding on region.

Definitely not identical.


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

not exactly, padding applies to the (non-line) block areas (boxes) generated by p

This appears to be a duplicate of the functionality provided by padding on div.

Don't know what you mean by duplicate. It is separate and independent.

In the absence of an explicitly line-based entity we haven't yet met the use case: padding on p seems to be the best place to put it given the duplication.

Not sure what you mean by duplication.

It can't go on span because line breaks are not predictable, unless we add the specification that in mapping to CSS box-decoration-break shall be "clone". Padding on span also has the problem described below.

span: applies to the contained text within the span.

more accurately, applies to the inline areas (boxes) generated by span

Right, yes. I meant that.

Adds to or overrides p-based tts:padding values?

padding on p and spans are treated separately and independentlty

Does this affect the interpretation of lineHeight?

It doesn't affect the computed value of tts:lineHeight. As for the actual height assigned to specific line areas (boxes), and since spans are non-replaced content, the following (from CSS2.1) applies [2]:

"Although margins, borders, and padding of non-replaced elements do not enter into the line box calculation, they are still rendered around inline boxes."

[2] http://www.w3.org/TR/CSS2/visudet.html#leading


I.e. is new lineHeight effectively increased by the padding on span to be lineHeight + padding_before + padding_after?

I think by "lineHeight" here you mean "line area (box) height". So the answer is no. Please keep in mind that the "line area(box) height" is not necessarily the same as the computed value of the tts:lineHeight property; that is, the following holds:

line area box height >= computed value(tts:lineHeight)




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.

i don't see any overlap between padding and spacing characters; they are quite distinct

Start and end padding creates a similar visual effect to spacing characters, and the two act additively in how much space is created, so they're not distinct when rendered. The "colour the background behind a word and extend it to half way between that word and the adjacent word's background" use case that John described shows how they are not distinct, at least if padding affects layout. To demonstrate:

<p tts:backgroundColor="black">
<span tts:padding="0c 0.5c 0c 1c">A word on a</span>
<span tts:backgroundColor="green" tts:padding="0c 0.5c 0c 0.5c">green</span>
<span tts:padding="0c 1c 0c 0.5c">background</span>
</p>

would render (in laid out foreground text) the same as:

<p tts:backgroundColor="black">
<span>A word on a green background</span>
</p>

assuming that 1c has been arranged to be equal to the width of one space character. The former example has two space characters missing. The background colours could have been omitted altogether to give exactly the same rendering.

Are you trying to achieve something like the attached?


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.
Agree this could be a problem, as shown in the third example HTML in the attached, where it was necessary to remove spaces between spans.

However, as shown in the fourth example in the attached, this can be fixed by inserting ZERO-WIDTH SPACE (&#x200B;) to ensure the presence of a space boundary.

Kind regards,

Nigel


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

Received on Monday, 9 December 2013 15:26:36 UTC