Re: tts:rubyReserve + tts:lineHeight (issue #779)

Can you provide a concrete example?

On Mon, May 21, 2018 at 4:53 PM Glenn Adams <glenn@skynav.com> wrote:

> No. The way I wrote the suggested refinement covers both the cases where
> the author specifies ruby font size and cases where the default ruby font
> size algorithm supplies that answer.
>
> On Mon, May 21, 2018 at 5:46 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>
>> > and the maximum  used bpd of the any inline area generated by a ruby
>> text container for that paragraph.
>>
>> The author would need to specify the ruby text font size that would
>> generate the ruby text container for that paragraph, since the ruby text
>> font size is not always 50% of the ruby container font size.
>>
>> On Mon, May 21, 2018 at 4:12 PM Glenn Adams <glenn@skynav.com> wrote:
>>
>>> Perhaps we could accommodate your concern by a slight change to the
>>> current default length computation: we could make it the maximum of the
>>> currently specified computation and the maximum  used bpd of the any inline
>>> area generated by a ruby text container for that paragraph.
>>>
>>> On Mon, May 21, 2018 at 3:22 PM, Pierre-Anthony Lemieux <
>>> pal@sandflow.com> wrote:
>>>
>>>> > How is this different from assigning a length value for lineHeight
>>>>
>>>> An author does not need to account for the presence of ruby text when
>>>> specifying tts:lineHeight. Instead, as I understand the specifications, the
>>>> processor automatically grows the line area height if the computed value of
>>>> tts:lineHeight is not sufficient to accommodate the ruby text (of the font
>>>> size specified by the author) -- see attached examples.
>>>>
>>>> Why should the author have to set the line height manually when using
>>>> tts:rubyReserve?
>>>>
>>>> Best,
>>>>
>>>> -- Pierre
>>>>
>>>> [image: 0.png]
>>>>
>>>> On Mon, May 21, 2018 at 1:00 PM Glenn Adams <glenn@skynav.com> wrote:
>>>>
>>>>> How is this different from assigning a length value for lineHeight in
>>>>> a non-ruby paragraph and not knowing whether the fonts used will fit the
>>>>> line? I think you could say exactly the same thing there:
>>>>>
>>>>> >It is therefore impossible for the author to accurately specify a
>>>>> <length>, and the default value might not be appropriate.
>>>>>
>>>>> On Mon, May 21, 2018 at 11:59 AM, Pierre-Anthony Lemieux <
>>>>> pal@sandflow.com> wrote:
>>>>>
>>>>>> Hi Cyril, Glenn et al.,
>>>>>>
>>>>>> The following is based on my working on implementing tts:rubyReserve
>>>>>> in imscJS.
>>>>>>
>>>>>> tts:rubyReserve is intended to reserve room to contain inline areas
>>>>>> generated by ruby annotations and emphasis marks, regardless of whether the
>>>>>> latter are present at a given instant in time.
>>>>>>
>>>>>> As currently specified, the amount of room reserved is explicitly
>>>>>> specified by the author as a <length>, or, if left unspecified, set to a
>>>>>> default value equal to 50% of the used value of the tts:lineHeight
>>>>>> applicable to the p element.
>>>>>>
>>>>>> I see a fundamental challenges with this approach:
>>>>>>
>>>>>> (a) neither tts:ruby nor tts:textEmphasis specify the amount of room
>>>>>> needed for ruby annotations and emphasis marks, respectively -- the amount
>>>>>> of room is left to the implementation. It is therefore impossible for the
>>>>>> author to accurately specify a <length>, and the default value might not be
>>>>>> appropriate.
>>>>>>
>>>>>> (b) the default value is not sufficient if the author specifies a
>>>>>> font size for ruby annotations that is different from the ruby base font
>>>>>> size.
>>>>>>
>>>>>> I suggest exploring the following tweak to the semantics of
>>>>>> tts:rubyReserve:
>>>>>>
>>>>>> """
>>>>>> The implementation reserves room for ruby annotations and emphasis
>>>>>> marks assuming:
>>>>>> - the font size of the base text is the same as that of the <p>
>>>>>> - the font size of the annotation/emphasis mark is specified by the
>>>>>> <length> or, if the <length> is not specified, computed according
>>>>>> to 10.2.21.1
>>>>>> """
>>>>>>
>>>>>> I will be on the road and unavailable for the next two TTWG calls. I
>>>>>> am however available today and tomorrow to discuss live​, and will be
>>>>>> available over email.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> -- Pierre
>>>>>>
>>>>>
>>>>>
>>>
>