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

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