Re: Status update re: TTML2 issue #1043 and a proposed test for "applies to"

SIL

On Sun, Jun 23, 2019 at 3:36 PM Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Good morning/evening,
>
> Quick update re: TTML2 issue #1043 before I become near incommunicado
> for a week.
>
> I have approved the following pull requests, which, while they do not
> resolve #1043, seem to provide valuable clarifications: #1087 (Clarify
> text combine application), #1085 (Clarify application of font
> variant), #1083 (Clarify application of font selection strategy),
> #1081 (Clarify text emphasis application), #1079 (Clarify text
> decoration application).
>
> There has been some progress re: #1043 (see thread at PR #1101) but
> uncertainty remains on the meaning of "applies to" -- this uncertainty
> is at the root of #1043 (and #1090 and #1091). For instance, does
> tts:color apply to ruby container span even though a ruby container
> span has no text nodes that tts:color can impact?
>
> As a result, I think more work is needed before PR #1089, #1092, #1093
> and #1101 can be disposed of.
>
> In the spirit of making progress and brainstorming, I suggest we
> explore clarifying the meaning of "applies to" using the following
> simple test:
>
> _a style property applies to an element if modifying the actual value
> of the style property on the element results in a change in rendering_
>

That won't work, since whether there is a change of rendering or not
depends on a variety of other factors as well, such as the following (not
meant to be all inclusive):

   - the content of the element; e.g., by this logic, many styles would not
   apply to empty elements, but would apply if the elemwere non-empty;
   - the resources available to and selected by the processor; e.g., font
   kerning won't have any affect on rendering if the selected font family
   (from a list of possible families) has no kerning information;
   - support for specific style values; e.g., in many cases we indicate
   that a processor can use the nearest supported value if a specific value is
   not supported;

What you are looking for is an algorithm that tells a processor when it can
optimize processing by ignoring certain content, and I keep repeating that
such optimization is an entirely optional aspect of a specific
implementation.

What we have here is exactly the same situation as we have with nailing
down a precise definition of "presentation related element" for the purpose
of optimizing the processing by pruning elements that cannot "affect the
presentation of content". When we adopted this language in TTML2 1e, we
said that this was an optimization and that it was the responsibility of
the implementation to prove that a given element could not affect
presentation if it were to be ignored. The same applies here with respect
to requiring a potentially optimizing implementation to ignore a style
property if it can prove that it could not affect presentation.

But we are not going to be able to write a definitive algorithm that
provides answers in either of these contexts: (1) [presentation related
element], and (2) potentially ignored style property. This is why would we
should not even being talking about attempting to define such an algorithm:
we will not succeed, and if we did manage to say something, you can be sure
it will be wrong in some edge case that we haven't exhaustively considered.
Furthermore, it will make future changes much more difficult and diminish
extensibility.


>
> Looking forward to your feedback, to the discussion and to closing the
> issue.
>
> Best,
>
> -- Pierre
>
>