Re: [TTML2] Issue-228: Ruby text support

On Thu, Sep 25, 2014 at 7:20 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

>   On Thu, Sep 25, 2014 at 3:48 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
>>  I've added the following review note to Issue-228:
>>
>>
>>  Alignment with the proposed approach for Rubys in HTML5 has been
>> achieved semantically but not syntactically with the current draft proposal.
>>
>
>  That (syntactic equivalence) has never been a goal or a requirement for
> any TTML feature adopted from other specifications.
>
>
>  Agreed it's not a requirement or a goal, but it's certainly an option.
>
>
>
>>  One of the impacts of this is that, in order to support Rubys,
>> processors must also support #nested-span.
>>
>
>  Correct. I don't see that as a problem.
>
>
>  Okay, others might, or might not – I've noted it because it's a subtlety
> that some might miss. Some profiles of TTML1 do not support #nested-span
> but may want to adopt Rubys, so it's possible that the chosen syntax would
> be problematic.
>
>     Another is that an extra level of translation is needed to create an
> HTML5 equivalent ISD including Rubys.
>
>  What do you mean by "extra level"? I don't see any extra level: it would
> simply be part of the same single translation layer.
>
>
>  I mean that a converter would not be able simply to duplicate the
> elements but would need to have a mapping from TTML span to HTML
> 'destination element' that's dependent on the value of the style
> attributes, specifically for Rubys.
>

In general, I assume the HTML conversion process can and will use any/all
document and document processing context state to perform the conversion.
However, there are at least two options here: one is to map to HTML or
XHTML element types, and another is to leave as span and map to CSS display
values according to CSS Ruby, in which case use of the HTML/XHTML element
types isn't required.


> That would be part of a general translation requirement that's already not
> a direct 1:1 element mapping; by choosing not to duplicate the HTML5 syntax
> we should recognise that we're not choosing the simplest possible
> translation scenario for this incremental feature, and we should understand
> the reasons why the chosen syntax is better in the context of TTML than the
> pre-existing HTML syntax.
>

The rationale for diverging is:

(1) the markup vocabulary situation in HTML for Ruby is already very
confused and divergent, e.g., the markup defined in HTML5 doesn't match
what was in included in XHTML based on the original Ruby Annotations spec:
Ian thought he could create a better design for folks who prefer markup
minimization;

(2) the overhead of adding a single style property, tts:ruby, to an
existing element tt:span, is much lower from a specification and schema
perspective than adding 6 new element types;

(3) our policy in TTML design has always been to minimize element type
proliferation;


>
>
>>
>>  Nigel
>>
>
>