Changelog between March 21, 2015 and March 28, 2015

Issues | Actions.

Get changelog


ISSUE-224 [3D text placement] (open)
ISSUE-229 [Mixed progression] (closed)
ISSUE-231 [Individual character rotation] (open)
ISSUE-302 [line spacing vs line area height] (open)
ISSUE-351 [Update IANA registration for TTML2] (open)
  • 2015-03-25 16:33:13:
    *<Nigel Megitt> As noted in meeting 2015-03-19 this is not a duplicate.
ISSUE-367 [#textAlign clarification] (pending review)
ISSUE-368 [ISD construction prunes <br/> erroneously] (open)
  • 2015-03-26 16:52:11:
    *<Nigel Megitt> I've just spotted that there's a Note in §8.1.4 div that hints at the same logic. It says "If some block area generated by a div element does not contain any child areas, then it is not expected to be presented." however if the only child areas are generated by <br> elements then I would expect the equivalent of a strut in the block progression dimension, corresponding to the sum of the heights of the lines implied by the <br>s to be taken into account in the presentation, and for the div's block area to be presented.

    It may also be helpful to indicate in §8.1.7 br that the presence of an active <br> is considered to cause the parent elements to be displayed, even if there are no content areas generated.
ISSUE-375 [ebu-extensions-imsc] (open)
  • 2015-03-26 14:49:19:
    *[nigel]: [meeting 2015-003-26] Andreas to propose some wording to make clear that ebutts:multiRowAlign applies only to tt:p and is inheritable.
ISSUE-376 [missing-XML-declaration] (open)
  • 2015-03-26 14:51:58:
    *Status changed to 'open'
ISSUE-377 [rounding-rules] (pending review)
ISSUE-378 [frame-rate-constraints] (pending review)
ISSUE-379 [ruby text font size inheritance] (open)
  • 2015-03-21 23:23:47:
    *<Glenn Adams> Created issue 'ruby text should used special inheritance algorithm' nickname ruby text font size inheritance owned by Glenn Adams on product TTML2, description 'in order to permit auto-sizing of ruby text annotations, the font size and line height styles should not be inherited on tts:ruby textContainer and, on tts:ruby text, should inherit only from the parent textContainer;

    that is, if textContainer is present and no font size or line height is specified on it, then it should not inherit these from its parent tts:ruby container; for tts:ruby text, if no font size or line height is specified, then it may inherit from its parent tts:ruby texContainer (if one exists, otherwise not)' non-public
  • 2015-03-26 14:56:33:
    *Status changed to 'open'
ISSUE-380 [Content area width is unclear] (raised)
  • 2015-03-26 16:32:21:
    *<Nigel Megitt> Created issue 'The width of content elements' areas is unclear, especially looking at the examples' nickname Content area width is unclear owned by Nigel Megitt on product TTML2, description 'The size of content elements relative to their parent elements and generated content elements is unclear. It is neither specified in §10.2.1 Style Attribute Vocabulary nor in §8.1 Content Element Vocabulary. It perhaps is specified in § Synchronic Flow Processing however there are no forward references directing the reader there. Even if it is in fact specified by a normative reference to XSL-FO and/or CSS, it would be helpful to add non-normative Notes where the information is most relevant, i.e. on style attributes whose effect is bounded by the applicable rectangular area.

    The terms "block display", "inline display" and "inline block display" are usefully defined in TTML2 but those definitions are not referenced everywhere they apply.

    Specifically, the implementation of the tts:backgroundColor, tts:backgroundImage and tts:border style attributes depends on the correct calculation of the rectangle to which they apply, and that rectangle is computed differently for spans than for the other content elements: only for spans is the size in the inline progression dimension related to the text content width; all the other elements' size in the inline progression dimension relates to the parent element's content rectangle minus any padding applied.

    The example for tts:backgroundColor is ambiguous and possibly misleading in this respect, because the width of the text has been chosen to be exactly the same as the width of the content area of the p that is coloured purple, making it appear to the casual observer that the purple box is shrunk to the maximum width of the inline areas generated for the text.

    Proposed resolutions:

    1. EITHER include normative text that specifies how the calculation of the rectangle to which the above listed attributes apply differs between spans and other content elements OR (if somehow the normative text is already strong enough) add non-normative notes to each attribute calling out the difference, or add the note to the introductory part of §10.2 and then reference it from the attributes.

    2. Add a diagram showing the width and height calculation (possibly this relates also to the resolution for Issue-302) that applies to each content element, and reference it from tts:backgroundColor, tts:backgroundImage and tts:border. This could be in the introductory part of §10.2 for example.

    3. Change the example for tts:backgroundColor to make it use a longest line length that is shorter than the width of the content area of the parent p element, or add a new example or a second p where that is the case.

    4. Ensure that the examples for tts:border do not reproduce the ambiguity.

    ' non-public


ACTION-365: Pierre-Anthony Lemieux to Review change proposal 21 in the light of closure of issue-229. (open)
ACTION-369: Nigel Megitt to Collate smpte issues and draft dispositions and circulate on reflector as a precursor to a liaison (closed)
ACTION-378: Pierre-Anthony Lemieux to Draft smpte request including dispositions from action-369 and backgroundcolor initial value question (open)
  • 2015-03-26 14:08:21:
    * Status changed to 'closed'
  • 2015-03-26 14:15:33:
    * Status changed to 'open'
ACTION-379: Nigel Megitt to Obtain png images for #linepadding and #multirowalign test cases. (open)
ACTION-380: Pierre-Anthony Lemieux to Create imsc 1 issues for removing initial value constraints, rounding definitions different to ttml1 and frame rate relationship to video (closed)
  • 2015-03-26 14:16:39:
    * Status changed to 'closed'
ACTION-381: Pierre-Anthony Lemieux to Prepare new list of changes to imsc 1 since cr1. (open)
ACTION-382: Nigel Megitt to Summarise action-369 end point (closed)
  • 2015-03-26 14:15:58:
    * Status changed to 'closed'
ACTION-383: Glenn Adams to Missing XML declaration (open)

David Singer <>, Nigel Megitt <>, Chairs, Thierry Michel <>, Philippe Le Hégaret <>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: changelog.php,v 1.34 2014-02-12 10:08:50 dom Exp $