IMSC 1 re: ISSUE-332, ISSUE-342 and ISSUE-339

Good morning/evening,

In preparation for our call tomorrow (and meeting next week), below is
my initial take on resolutions to selected outstanding IMSC 1 issues.

Looking forward to the discussion.

Best,

-- Pierre

ISSUE-332 #cellResolution support
=================================

Background: IMSC 1 currently forbids specifying ttp:cellResolution.

Editor's input: AFAIK, specifying ttp:cellResolution only affects the
calculation of the value of the 'c' metric. Thus no additional HRM
and/or layout engine feature are required.

Proposed resolution: Permit any value of ttp:cellResolution to be specified.

ISSUE-342 Add ebutts:multiRowAlign and ebutts:linePadding attributes
to the IMSC Text Profile
=============================================================================================

Background: These two features are intended to enable timed-text
styling consistent with European practice (see [1]). These features
require changes to the IMSC 1 layout engine. They features can however
be ignored by a processor and still yields a reasonable presentation.
No changes to the IMSC 1 HRM are necessary.

Editor's input: I am not aware of implementations supporting these features.

Proposed resolution: Add ebutts:multiRowAlign and ebutts:linePadding
to the Text Profile, referencing the EBU document directly. If
interoperability cannot be demonstrated within the CR timeframe, then
the features can be removed or their rendering recommended rather than
mandated.

[1] Annex C and D at https://tech.ebu.ch/docs/tech/tech3380.pdf

ISSUE-339 Allow the use of #overflow
====================================

Background: Per TTML1, tts:overflow is set to 'visible' means "region
composition and layout must be performed as if the region's width and
height were unconstrained". IMSC 1 currently forbids
tts:overflow='visible'. The idea to make sure that the region extent
is deterministic so that (a) the document complexity can be
constrained by the HRM (which uses region extent as one of its
criterion) and (b) authors can have confidence that the document will
be rendered as authored.

Editor's input: Use cases where tts:overflow='visible' provides a
benefit to authors are unclear in my mind: if text overflows during
authoring, the author can simply increase the region's extents, and,
in any event, tts:overflow='visible' does not guarantee that the text
will be shown, e.g. the overflow could overlap/be hidden by other
regions.

Proposed resolution: Retain current restriction on #overflow.

Received on Wednesday, 10 September 2014 23:05:36 UTC