Re: [ttml2] font*-p features

> In particular, does it map a TTML p with line height of normal to an HTML
p with a line height of normal?

Yes, that is what has yielded the most consistent results so far -- as far
as users are concerned.
On Sun, May 27, 2018 at 9:10 PM Glenn Adams <glenn@skynav.com> wrote:



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

Received on Sunday, 27 May 2018 19:22:43 UTC