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

Hi Pierre,

Thanks for the additional explanations.

>>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?

The choice of names that happen to be generic font family names may need
an explanatory note to clarify that the intent is not to derive the
generic font family that the computed font family would fall into, and
apply the layout metrics from the relevant reference font, if there is one.

Put another way: A given generic font family name may be mapped by an
implementation to one of a number of fonts that fall into the set
described by that generic name. For example,

proportionalSansSerif = [Arial, Helvetica, Lucida Sans, Verdana, ...]

If I've understood rightly, there is no requirement in IMSC 1 for
implementations to layout text whose computed font family name is "Lucida
Sans" according to the Linotype Helvetica font metrics, simply because
they fall into the same generic family.

However there is a requirement that if the computed font family name is
"proportionalSansSerif" then the text is laid out according to the
Linotype Helvetica reference font metrics even if the implementation
chooses to draw the glyphs from the Lucida Sans font.




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

Looks to me like this doesn't meet worldwide caption requirements. For
example it is common practice in UK to use the Tiresias font for broadcast
subtitles, as developed and recommended by one of the groups advocating
for accessibility, the RNIB. There's no reference font defined for this:
laying out the glyphs according to either of the reference fonts in IMSC 1
will likely result in text that's hard to read and looks bad.

It's not a reasonable choice to offer to authors: either have text laid
out deterministically or choose your font, but if your font isn't one that
we happen to have pre-planned for then you can't have both.

There are always going to be examples where the presentation text layout
is not identical to what was expected at the point of authoring, even if
reference fonts may be useful for some cases. When that happens, we have
to have a way to deal with the potential for overflow, and tts:overflow
allows for some authorial control. It's by no means a perfect solution but
it's the best one available right now.




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

This is out of scope of TTML and IMSC right now and therefore not
something we can reliably assert - if you want/need this behaviour to be
supported then it needs to be in the spec.




Can we revisit the assertion that overflow would cause a problem relating
to the HRM?

First point on this: HRM is for calculating complexity of a document not
for implementing a renderer, and the document complexity is not
fundamentally affected by overflow: you could simply add an assumption
that overflow need not be used when calculating the complexity and
continue with it as now. In fact (my next point below) this already
appears to be the case - there's nothing in the HRM that would be changed
by overflow. 

Second point: digging in to the HRM the impact is in fact minimal, maybe
none:
From §8.1.2:
>The Presentation Compositor shall render in Presentation Buffer Pn each
>successive intermediate synchronic document En using the following steps
>in order:

>1. clear the pixels, except for the first intermediate synchronic
>document E0 for the which the pixels of P0 shall be assumed to have been
>cleared;

This means all the pixels in the graphics plane - so unaffected by
overflow.

>2. paint, according to stacking order, all background pixels for each
>region;

Region background size is unaffected by overflow.

>3. paint all pixels for background colors associated with text or image
>subtitle content; and

This only impacts text content. The normalised area to be painted is
"PAINT(En) = ∑Ri∈Rp SIZE(Ri) ∙ NBG(Ri)" Neither SIZE(Ri) nor NBG(Ri) are
affected by overflow. You could argue that SIZE(Ri) is incorrect if the
region area needs to be expanded to accommodate the overflowed text, but I
don't believe it does - look at the example for tts:overflow in TTML1SE in
which the background doesn't extend to include the overflowed text.

My point of doubt on this is if a background colour is specified on a span
explicitly - I wonder if background would be drawn on overflowed text in
that case. Can anyone answer that question?


>4. paint the text or image subtitle content.

This (DURT(En)) is a function of the number of glyphs and for each one if
it is a CJK ideograph or not, and does not relate to the location of each
glyph. Therefore it's unaffected by overflow.


If we can agree that the HRM is unaffected by overflow would that remove
the objection to permitting it?

Kind regards,

Nigel




On 11/09/2014 18:11, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:

>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 Friday, 12 September 2014 09:47:19 UTC