Re: [ttml2] font*-p features

On Sun, May 27, 2018 at 12:55 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> > So, for TTML1, you end up using font family, size, style, and weight to
> resolve the default (normal) line height.
>
> The fact that the value of the style properties computed on each span is
> used by the implementation to determine line height does not mean that the
> style properties apply to the <p>. In other words, it is sufficient for the
> style properties to apply to the <span>s with the <p> for the
> implementation to use their computed value there to compute line height.
>

How does imscJS handle line height? In particular, does it map a TTML p
with line height of normal to an HTML p with a line height of normal? If
so, then does it perform any other special handling for line height normal?


>
> Maybe I am missing something obvious.
> On Sun, May 27, 2018 at 8:25 PM Glenn Adams <glenn@skynav.com> wrote:
>
> > The essential point to understand is the all TTML1 issues actually do use
> > the these semantics, but did so because of logical necessity rather than
> > because the TTML1 spec made this explicit.
>
> > That it was (is) logically necessary is obvious if you consider how to
> resolve
> > the meaning of the normal keyword for line height. To resolve its
> computed
> > value, you must know the descent, ascent, and line gap (separator) for
> the
> > font associated with the paragraph, which means you must know the
> specific
> > font resource, which mean you must use font family, style, weight.
>
> > So, for TTML1, you end up using font family, size, style, and weight to
> resolve
> > the default (normal) line height.
>
>
> > On Sun, May 27, 2018 at 9:27 AM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> wrote:
>
> >> Hi Glenn et al.,
>
> >> Apologies for the belated reply, I have been on the road, and had not
> >> realized this significant change that happened between TTML1 and TTML2,
> >> i.e. TTML2 applying style properties applying to <p> in addition to
> <span>,
> >> where they only apply to <span> in TTML1.
>
> >> I struggle to understand this change since it has not been an issue with
> >> interoperability in TTML1. Do you have a specific test case in mind?
>
> >> > Only for the purpose of determining the default line height for a
> >> paragraph (used to resolve 'normal'),
> >> > since one has to resolve the font properties to a specific font
> resource
> >> (in order to obtain the ascent, descent, and line gap (separation) data
> >> from the font).
>
> >> An implementation determines the height of each line box based on many
> >> factors, e.g. the
> >> styles applied to the <span>s within the line box, tts:lineHeight
> >> specified on <p>, etc... The styles do not need to apply to the <p> for
> >> this to
> >> happen. Can you provide a case where this is not the case? Perhaps
> specific
> >> code within TTPE?
>
> >> Best,
>
> >> -- Pierre
>
>
> >> On Mon, May 21, 2018 at 6:40 PM Glenn Adams <glenn@skynav.com> wrote:
>
> >> > Any comments on this folks? I suggest there are a few different
> options
> >> that would go along with removing the font*-p features:
>
> >> > add informative note under each font* property with a font*-p feature
> >> that the specific listing of p was implied (but undocumented) in TTML1
> (and
> >> perhaps should be added in TTML1 3ed);
> >> > remove citation of p under application, but add a note like (1) anyway
> >> > instead of using a note, add a special semantics subsection (or
> >> sub-sub-section if already present) that documents the semantics around
> p
> >> use of the font* property
>
>
> >> > On Sun, May 20, 2018 at 9:41 PM, Glenn Adams <glenn@skynav.com>
> wrote:
>
> >> >> I'm having second thoughts about adding the font*-p features in
>
> https://github.com/w3c/ttml2/pull/664/commits/
> 640f28ede06c0175e5d260af0790fef913e643ac
> >> .
>
> >> >> The reason we added these is because we explicitly added 'p' as one
> of
> >> the elements to which these font* properties applied. Now, why do they
> >> apply? Only for the purpose of determining the default line height for a
> >> paragraph (used to resolve 'normal'), since one has to resolve the font
> >> properties to a specific font resource (in order to obtain the ascent,
> >> descent, and line gap (separation) data from the font).
>
> >> >> But the thing is: all TTML1 implementations had to use this algorithm
> >> already, so effectively already applied these properties to 'p'. So in
> >> reality, we aren't adding new functionality here (that might warrant
> having
> >> new feature designators), but only rectifying a missing behavior
> >> specification (in TTML1) that was already implemented in reality (by
> both
> >> old implementations, like DFXPVW, and new implementations, like IMSCJS,
> >> which maps to CSS (which already applies these font properties to P in
> this
> >> fashion).
>
> >> >> I recommend we remove the new font*-p features and instead add notes
> to
> >> each of the properties that explains that the addition of 'p' to this
> list
> >> of applied elements serves only to document existing behavior consistent
> >> with TTML1 implementations.
>
> >> >> However, if someone knows of a TTML1 (or IMSC) implementation that
> does
> >> not use these semantics for obtaining the default line height of a
> >> paragraph, then we will need to discuss this further.
>