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

Hi Nigel et al.,

My feedback below.

> is it saying that for any font that would fall into the generic font
> family "monospaceSerif" or "proportionalSansSerif" the glyphs must be laid
> out as though they were in the specified reference font?

The intent is that text for which "monospaceSerif" or
"proportionalSansSerif" is specified would be assumed to have been
laid out using the specified reference font.

In practice, it means that an authoring tool would use the reference
font (or one with equivalent metrics) when the author selects
"monospaceSerif" or "proportionalSansSerif" as the font. An authoring
tool may also choose to make "monospaceSerif" or
"proportionalSansSerif" the default font.

> 3. If an author wishes to choose a different font family,
> which may still be generic, such as proportionalSerif or monospaceSansSerif,
> is it correct that the reference font does not apply

Yes. Reference fonts are defined for "monospaceSerif" or
"proportionalSansSerif" at this point.

> and the problem of
> rendered text widths not being accurately predictable at
> authoring time still occurs?

Yes. Authors that desire accurate control can use font families for
which reference fonts are defined.

In all cases, an implementation can always choose to extend regions
and/or change font size to match system requirements, user font
preferences, etc...

> Is this not related to generic font family at all, and only
> refers to the actual computed font family name?

Not sure what you mean. Can you elaborate?

Thanks,

-- Pierre

On Thu, Sep 11, 2014 at 8:58 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> Hi Pierre,
>
> I'm not sure if I've understood section 8.2 Reference Fonts as intended.
> Maybe answers to these questions can help:
>
> 1. is it saying that for any font that would fall into the generic font
> family "monospaceSerif" or "proportionalSansSerif" the glyphs must be laid
> out as though they were in the specified reference font?
>
> 2. Is this not related to generic font family at all, and only refers to
> the actual computed font family name?
>
> 3. If an author wishes to choose a different font family, which may still
> be generic, such as proportionalSerif or monospaceSansSerif, is it correct
> that the reference font does not apply and the problem of rendered text
> widths not being accurately predictable at authoring time still occurs?
>
> Kind regards,
>
> Nigel
>
>
>
> On 11/09/2014 16:38, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:
>
>>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 17:12:27 UTC