Re: [ttml2] font*-p features

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