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

Hi John et al.,

Some follow-up thoughts re: ISSUE-339 based on this morning's telecon.

> since it requires an author to have prior knowledge of all fonts and
> rendering techniques (including kerning and leading) that might be
> used in all potential devices that render from IMSC text.

IMSC 1 defines reference fonts to allow an author to create a document
with regions sized appropriately. An implementation that ultimately
uses a font with different metrics (based on system requirements, or
user preferences, or...) can resize regions accordingly and
automatically. Authorial control of tts:overflow is not needed.

Would adding a note in the specification along these lines address the issue?

Best,

-- Pierre

On Thu, Sep 11, 2014 at 12:01 AM, John Birch
<John.Birch@screensystems.tv> wrote:
> Re: multiRowAlign and linePadding... I am happy to move directly to:
>
> "their rendering recommended rather than
> mandated."
>
> Re overflow...
> Your assumption regarding the ability of an author to (pre)determine necessary region size is unfounded in practise, since it requires an author to have prior knowledge of all fonts and rendering techniques (including kerning and leading) that might be used in all potential devices that render from IMSC text. I am certain from experience that this is impractical and unlikely. Consequently a more likely outcome (if ocerflow remains hidden) is that authors will over size regions which would have potential impact on achieving identical justification or vertical alignment between those devices using different fonts / rendering.
>
> Best regards,
> John
>
> John Birch | Strategic Partnerships Manager | Screen
> Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
> Mobile : +44 7919 558380 | Fax : +44 1473 830078
> John.Birch@screensystems.tv | www.screensystems.tv | https://twitter.com/screensystems
>
> Visit us at
> IBC, RAI Amsterdam, 12-16 Sept, stand 1.C49
>
> P Before printing, think about the environment----- Original Message -----
> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
> Sent: Thursday, September 11, 2014 12:04 AM
> To: public-tt@w3.org <public-tt@w3.org>
> Subject: 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.
>
>
> 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 Thursday, 11 September 2014 15:39:49 UTC